search for: copy_page

...[.] strcmp 2.66% ld-2.24.so [.] _dl_relocate_object 2.58% ld-2.24.so [.] _dl_lookup_symbol_x 1.85% ld-2.24.so [.] _dl_name_match_p 1.46% [kernel.kallsyms] [k] copy_page 1.38% ld-2.24.so [.] _dl_map_object 1.30% [kernel.kallsyms] [k] unmap_page_range 1.28% [kernel.kallsyms] [k] filemap_map_pages 1.26% libLLVMSupport.so.6.0.0svn [.] sstep % grep -v '...

>>> Dan Magenheimer <dan.magenheimer@oracle.com> 13.01.09 00:29 >>> >I''m guessing the gcc optimizer for the memcpy code was tuned >for an Intel pipeline... Jan, were you measuring on an >AMD processor? Oh, actually my previous reply was without pushing my thinking fully back to what I was doing (and measuring) back then. I really measured on quad core

...n I only measured kernel builds (where the results are not hinting at a meaningful improvement), I now found time to do a more specific analysis: page clearing is being improved by about 20%, page copying doesn''t seem to significantly benefit (though that may be an effect of the simplistic copy_page() implementation Xen currently uses) - nevertheless I would think that if one function is supported by the hypervisor, then the other should also be. The hypervisor patch is below (using temporary numbers for the newly added sub-hypercalls), the Linux patch didn''t change over the first su...

...e is dirtied when it''s being cleared. */ + paging_mark_dirty(d, mfn); + + ptr = fixmap_domain_page(mfn); + clear_page(ptr); + fixunmap_domain_page(ptr); + + put_page_and_type(page); + break; + } + + case MMUEXT_COPY_PAGE: + { + const unsigned char *src; + unsigned char *dst; + unsigned long src_mfn; + + src_mfn = gmfn_to_mfn(FOREIGNDOM, op.arg2.src_mfn); + okay = get_page_from_pagenr(src_mfn, FOREIGNDOM); + if ( unlikely(!okay) ) +...

...like arm64 and sparc do the cache flushing on copy_to_user_page and copy_user_page, not on kunmap. #define copy_user_page(to,from,vaddr,pg) __cpu_copy_user_page(to, from, vaddr) void __cpu_copy_user_page(void *kto, const void *kfrom, unsigned long vaddr) { struct page *page = virt_to_page(kto); copy_page(kto, kfrom); flush_dcache_page(page); } #define copy_user_page(to, from, vaddr, page) \ do { copy_page(to, from); \ sparc_flush_page_to_ram(page); \ } while (0) And they do nothing on kunmap: static inline void kunmap(struct page *page) { BUG_ON(in_interrupt()); if (!PageHighMem(page))...

...age *to, struct page *from) +{ + void *vfrom, *vto; + + if (likely(xen_feature(XENFEAT_highmem_assist)) + && (PageHighMem(from) || PageHighMem(to))) { + unsigned long from_pfn = page_to_pfn(from); + unsigned long to_pfn = page_to_pfn(to); + struct mmuext_op meo; + + meo.cmd = MMUEXT_COPY_PAGE; + meo.arg1.mfn = pfn_to_mfn(to_pfn); + meo.arg2.src_mfn = pfn_to_mfn(from_pfn); + if (mfn_to_pfn(meo.arg2.src_mfn) == from_pfn + && mfn_to_pfn(meo.arg1.mfn) == to_pfn + && HYPERVISOR_mmuext_op(&meo, 1, NULL, DOMID_SELF) == 0) + return; + } + + vfrom = kmap_atomic...

...'ll still suffer from the spectre-v1 fix, > although I exclude they have to suffer the SMAP > slowdown/feature). Those may require some additional flushing than the > current copy-user model requires. > > As a rule of thumb any arch where copy_user_page doesn't define as > copy_page will require some additional cache flushing after the > kmap. Supposedly with vmap, the vmap layer should have taken care of > that (I didn't verify that yet). vmap_page_range()/free_unmap_vmap_area() will call fluch_cache_vmap()/flush_cache_vunmap(). So vmap layer should be ok. Thank...

Hi gang, Here''s some trivial cleanups that I''ve built up while reading through the code. They''ve been run through xfstests -g quick. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

...BLE, - PFN_DOWN(__pa(initial_page_table))); + PFN_DOWN(__pa_symbol(initial_page_table))); set_page_prot(initial_page_table, PAGE_KERNEL); set_page_prot(initial_kernel_pmd, PAGE_KERNEL); @@ -2036,7 +2037,7 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) copy_page(initial_page_table, pgd); initial_page_table[KERNEL_PGD_BOUNDARY] = - __pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT); + __pgd(__pa_symbol(initial_kernel_pmd) | _PAGE_PRESENT); set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO); set_page_prot(initial_page_table, PAGE_KERNEL_RO); @@ -2045,8...

...BLE, - PFN_DOWN(__pa(initial_page_table))); + PFN_DOWN(__pa_symbol(initial_page_table))); set_page_prot(initial_page_table, PAGE_KERNEL); set_page_prot(initial_kernel_pmd, PAGE_KERNEL); @@ -2036,7 +2037,7 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) copy_page(initial_page_table, pgd); initial_page_table[KERNEL_PGD_BOUNDARY] = - __pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT); + __pgd(__pa_symbol(initial_kernel_pmd) | _PAGE_PRESENT); set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO); set_page_prot(initial_page_table, PAGE_KERNEL_RO); @@ -2045,8...

...ally tagged data caches (they'll still suffer from the spectre-v1 fix, although I exclude they have to suffer the SMAP slowdown/feature). Those may require some additional flushing than the current copy-user model requires. As a rule of thumb any arch where copy_user_page doesn't define as copy_page will require some additional cache flushing after the kmap. Supposedly with vmap, the vmap layer should have taken care of that (I didn't verify that yet). There are some accessories like copy_to_user_page() copy_from_user_page() that could work and obviously defines to raw memcpy on x86 (the...

...t was the only safe one). Before we can leverage your idea to flush the dcache on kunmap in common code without having to sacrifice performance in arch code, we'd need to change all other archs to add the cache flushes on kunmap too, and then remove the cache flushes from the other places like copy_page or we'd waste CPU. Then you'd have the best of both words, no double flush and kunmap would be enough. Thanks, Andrea

On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote: > > On 2019/3/12 ??2:14, David Miller wrote: > > From: "Michael S. Tsirkin" <mst at redhat.com> > > Date: Mon, 11 Mar 2019 09:59:28 -0400 > > > > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: > > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote: > > >

On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote: > > On 2019/3/12 ??2:14, David Miller wrote: > > From: "Michael S. Tsirkin" <mst at redhat.com> > > Date: Mon, 11 Mar 2019 09:59:28 -0400 > > > > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote: > > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote: > > >

...f similar systems that can share kernel binaries. > Or do you do boot-time rewriting, like a number of other arches do? We don't rewrite the code (as in the .text of the vmlinux binary) but we do runtime code generation for a few highly performance sensitive area of the kernel code such as copy_page() or TLB exception handlers. This allows more flexibility than just inserting templates into the kernel code. Downside - it means we have some of the complexity of as and ld in the kernel. Ralf

...f similar systems that can share kernel binaries. > Or do you do boot-time rewriting, like a number of other arches do? We don't rewrite the code (as in the .text of the vmlinux binary) but we do runtime code generation for a few highly performance sensitive area of the kernel code such as copy_page() or TLB exception handlers. This allows more flexibility than just inserting templates into the kernel code. Downside - it means we have some of the complexity of as and ld in the kernel. Ralf

...M_TYPECHECKS ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 64 ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 65 extern void clear_page (void *page); ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 66 extern void copy_page (void *to, void *from); ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 67 ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 68 /* ^1da177e4c3f41 include/asm-ia64/page.h Linus Torvalds 2005-04-16 69 * clear_user_page() and copy_user...

On Mon, Mar 11, 2019 at 03:40:31PM +0800, Jason Wang wrote: > > On 2019/3/9 ??3:48, Andrea Arcangeli wrote: > > Hello Jeson, > > > > On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: > > > Just to make sure I understand here. For boosting through huge TLB, do > > > you mean we can do that in the future (e.g by mapping more userspace > >

On Mon, Mar 11, 2019 at 03:40:31PM +0800, Jason Wang wrote: > > On 2019/3/9 ??3:48, Andrea Arcangeli wrote: > > Hello Jeson, > > > > On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote: > > > Just to make sure I understand here. For boosting through huge TLB, do > > > you mean we can do that in the future (e.g by mapping more userspace > >

...\ +#define kunmap_atomic(__addr) \ +do { \ + BUILD_BUG_ON(__same_type((__addr), struct page *)); \ + __kunmap_atomic(__addr); \ + pagefault_enable(); \ + preempt_enable(); \ } while (0) - /* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */ #ifndef clear_user_highpage static inline void clear_user_highpage(struct page *page, unsigned long vaddr) --- a/mm/Kconfig +++ b/mm/Kconfig @@ -872,4 +872,7 @@ config ARCH_HAS_HUGEPD config MAPPING_DIRTY_HELPERS bool +config KMAP_LOCAL + bool + endmenu --- a/mm/highmem.c +++ b/mm...