search for: release_page

...t;hch at lst.de> > Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> > Acked-by: Michal Hocko <mhocko at suse.com> [..] > diff --git a/mm/swap.c b/mm/swap.c > index 7ede3eddc12a..83107410d29f 100644 > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -740,17 +740,6 @@ void release_pages(struct page **pages, int nr) > if (is_huge_zero_page(page)) > continue; > > - /* Device public page can not be huge page */ > - if (is_device_public_page(page)) { > - if (locked_pgdat) { &gt...

...;s > series (and Ira will have to rebase/repost it), so I think there is > nothing to do at this moment - unless you are saying there is a > problem with the series in CH's git tree? There is a problem with the series in CH's tree. It removes the ->page_free() callback from the release_pages() path because it goes too far and removes the put_devmap_managed_page() call.

On Fri, Jun 28, 2019 at 11:52 AM Christoph Hellwig <hch at lst.de> wrote: > > On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote: > > There is a problem with the series in CH's tree. It removes the > > ->page_free() callback from the release_pages() path because it goes > > too far and removes the put_devmap_managed_page() call. > > release_pages only called put_devmap_managed_page for device public > pages. So I can't see how that is in any way a problem. It's a bug that the call to put_devmap_managed_page() was ga...

...y: Jason Gunthorpe <jgg at mellanox.com> > > Acked-by: Michal Hocko <mhocko at suse.com> > [..] > > diff --git a/mm/swap.c b/mm/swap.c > > index 7ede3eddc12a..83107410d29f 100644 > > --- a/mm/swap.c > > +++ b/mm/swap.c > > @@ -740,17 +740,6 @@ void release_pages(struct page **pages, int nr) > > if (is_huge_zero_page(page)) > > continue; > > > > - /* Device public page can not be huge page */ > > - if (is_device_public_page(page)) { > > -...

...+0x12/0x20 [354008.101011] [<ffffffff81006d0f>] ? xen_restore_fl_direct_reloc+0x4/0x4 [354008.101017] [<ffffffff81071153>] ? arch_local_irq_restore+0x7/0x8 [354008.101024] [<ffffffff8135049f>] ? _raw_spin_unlock_irqrestore+0xe/0xf [354008.101031] [<ffffffff810be895>] ? release_pages+0xf4/0x14d [354008.101038] [<ffffffff810de78b>] ? free_pages_and_swap_cache+0x48/0x60 [354008.101045] [<ffffffff810cf527>] ? tlb_flush_mmu+0x37/0x50 [354008.101049] [<ffffffff810cf54c>] ? tlb_finish_mmu+0xc/0x31 [354008.101054] [<ffffffff810d5e79>] ? exit_mmap+0xc4/0xe...

...f810674fa>] warn_slowpath_common+0x7a/0xb0 [ 3009.856857] [<ffffffff81067545>] warn_slowpath_null+0x15/0x20 [ 3009.866562] [<ffffffff81042041>] untrack_pfn+0xa1/0xb0 [ 3009.876201] [<ffffffff8111a59b>] unmap_single_vma+0x86b/0x8e0 [ 3009.885895] [<ffffffff81100f16>] ? release_pages+0x196/0x1f0 [ 3009.895488] [<ffffffff8111a65c>] unmap_vmas+0x4c/0xa0 [ 3009.905134] [<ffffffff8111c8fa>] exit_mmap+0x9a/0x180 [ 3009.914706] [<ffffffff81064e72>] mmput+0x52/0xd0 [ 3009.924252] [<ffffffff810652b7>] dup_mm+0x3c7/0x510 [ 3009.933839] [<ffffffff81065fd5...

...state transition from volatile to volatile. Not what we want. To get rid of these state transitions as well special variants of put_page_testzero/ page_cache_release are introduced that do not attempt to make the page volatile. page_cache_release_nocheck is then used in free_page_and_swap_cache and release_pages. This makes the unmap of ptes state transitions free. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- include/linux/mm.h | 11 ++++-- include/linux/pagemap.h | 5 ++ include/linux/swap.h | 2 - mm/filemap.c | 81 +++++++++++++++++++++++++++++++++...

...state transition from volatile to volatile. Not what we want. To get rid of these state transitions as well special variants of put_page_testzero/ page_cache_release are introduced that do not attempt to make the page volatile. page_cache_release_nocheck is then used in free_page_and_swap_cache and release_pages. This makes the unmap of ptes state transitions free. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- include/linux/mm.h | 11 ++++-- include/linux/pagemap.h | 5 ++ include/linux/swap.h | 2 - mm/filemap.c | 81 +++++++++++++++++++++++++++++++++...

On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote: > There is a problem with the series in CH's tree. It removes the > ->page_free() callback from the release_pages() path because it goes > too far and removes the put_devmap_managed_page() call. release_pages only called put_devmap_managed_page for device public pages. So I can't see how that is in any way a problem.

...] [<ffffffff81006d0f>] ? > xen_restore_fl_direct_reloc+0x4/0x4 > [354008.101017] [<ffffffff81071153>] ? arch_local_irq_restore+0x7/0x8 > [354008.101024] [<ffffffff8135049f>] ? > _raw_spin_unlock_irqrestore+0xe/0xf > [354008.101031] [<ffffffff810be895>] ? release_pages+0xf4/0x14d > [354008.101038] [<ffffffff810de78b>] ? > free_pages_and_swap_cache+0x48/0x60 > [354008.101045] [<ffffffff810cf527>] ? tlb_flush_mmu+0x37/0x50 > [354008.101049] [<ffffffff810cf54c>] ? tlb_finish_mmu+0xc/0x31 > [354008.101054] [<ffffffff810d5e79&...

...86413] RBP: 000000000269c000 R08: 0000000000000000 R09: ffffea0000dd4740 [ 2504.186413] R10: ffffea0001755700 R11: ffff8880cc62d120 R12: 0000000002794000 [ 2504.186414] R13: 000000000269b000 R14: ffffc900036cbdf0 R15: ffff8880572434d8 [ 2504.186414] ? unmap_page_range+0x420/0x9b0 [ 2504.186414] ? release_pages+0x175/0x390 [ 2504.186414] unmap_vmas+0x7c/0xe0 [ 2504.186415] exit_mmap+0xa4/0x190 [ 2504.186415] mmput+0x3b/0x100 [ 2504.186415] do_exit+0x276/0xc10 [ 2504.186415] do_group_exit+0x35/0xa0 [ 2504.186415] __x64_sys_exit_group+0xf/0x10 [ 2504.186416] do_syscall_64+0x43/0x120 [ 2504.186416]...

...86413] RBP: 000000000269c000 R08: 0000000000000000 R09: ffffea0000dd4740 [ 2504.186413] R10: ffffea0001755700 R11: ffff8880cc62d120 R12: 0000000002794000 [ 2504.186414] R13: 000000000269b000 R14: ffffc900036cbdf0 R15: ffff8880572434d8 [ 2504.186414] ? unmap_page_range+0x420/0x9b0 [ 2504.186414] ? release_pages+0x175/0x390 [ 2504.186414] unmap_vmas+0x7c/0xe0 [ 2504.186415] exit_mmap+0xa4/0x190 [ 2504.186415] mmput+0x3b/0x100 [ 2504.186415] do_exit+0x276/0xc10 [ 2504.186415] do_group_exit+0x35/0xa0 [ 2504.186415] __x64_sys_exit_group+0xf/0x10 [ 2504.186416] do_syscall_64+0x43/0x120 [ 2504.186416]...

Hi: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. Test shows about 24% improvement on TX PPS. It should benefit other cases as well. Please review Jason Wang (3): vhost: generalize adding used elem vhost: fine grain userspace memory

Hi: This series tries to access virtqueue metadata through kernel virtual address instead of copy_user() friends since they had too much overheads like checks, spec barriers or even hardware feature toggling. Test shows about 24% improvement on TX PPS. It should benefit other cases as well. Please review Jason Wang (3): vhost: generalize adding used elem vhost: fine grain userspace memory

...000000000000000 R09: > ffffea0000dd4740 > [ 2504.186413] R10: ffffea0001755700 R11: ffff8880cc62d120 R12: > 0000000002794000 > [ 2504.186414] R13: 000000000269b000 R14: ffffc900036cbdf0 R15: > ffff8880572434d8 > [ 2504.186414] ? unmap_page_range+0x420/0x9b0 > [ 2504.186414] ? release_pages+0x175/0x390 > [ 2504.186414] unmap_vmas+0x7c/0xe0 > [ 2504.186415] exit_mmap+0xa4/0x190 > [ 2504.186415] mmput+0x3b/0x100 > [ 2504.186415] do_exit+0x276/0xc10 > [ 2504.186415] do_group_exit+0x35/0xa0 > [ 2504.186415] __x64_sys_exit_group+0xf/0x10 > [ 2504.186416] do_sys...

On Sat, Aug 03, 2019 at 05:36:13PM -0400, Michael S. Tsirkin wrote: > On Fri, Aug 02, 2019 at 02:24:18PM -0300, Jason Gunthorpe wrote: > > On Fri, Aug 02, 2019 at 10:27:21AM -0400, Michael S. Tsirkin wrote: > > > On Fri, Aug 02, 2019 at 09:46:13AM -0300, Jason Gunthorpe wrote: > > > > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: > > > > >

On Sat, Aug 03, 2019 at 05:36:13PM -0400, Michael S. Tsirkin wrote: > On Fri, Aug 02, 2019 at 02:24:18PM -0300, Jason Gunthorpe wrote: > > On Fri, Aug 02, 2019 at 10:27:21AM -0400, Michael S. Tsirkin wrote: > > > On Fri, Aug 02, 2019 at 09:46:13AM -0300, Jason Gunthorpe wrote: > > > > On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: > > > > >

...15% 2.26% queue_spin_lock_slowpath N/A 4.82% The top spinlock related entries in the perf profile for the 3.19 kernel at 1000 users were: 7.40% reaim [kernel.kallsyms] [k] _raw_spin_lock_irqsave |--58.96%-- rwsem_wake |--20.02%-- release_pages |--15.88%-- pagevec_lru_move_fn |--1.53%-- get_page_from_freelist |--0.78%-- __wake_up |--0.55%-- try_to_wake_up --2.28%-- [...] 3.13% reaim [kernel.kallsyms] [k] _raw_spin_lock |--37.55%-- fr...

...15% 2.26% queue_spin_lock_slowpath N/A 4.82% The top spinlock related entries in the perf profile for the 3.19 kernel at 1000 users were: 7.40% reaim [kernel.kallsyms] [k] _raw_spin_lock_irqsave |--58.96%-- rwsem_wake |--20.02%-- release_pages |--15.88%-- pagevec_lru_move_fn |--1.53%-- get_page_from_freelist |--0.78%-- __wake_up |--0.55%-- try_to_wake_up --2.28%-- [...] 3.13% reaim [kernel.kallsyms] [k] _raw_spin_lock |--37.55%-- fr...

...npages, write, pages); + if (npinned != npages) + goto err; + + vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL); + if (!vaddr) + goto err; + + map->pages = pages; + map->addr = vaddr + (uaddr & (PAGE_SIZE - 1)); + map->npages = npages; + + return 0; + +err: + if (npinned > 0) + release_pages(pages, npinned); + kfree(pages); + return -EFAULT; +} + +static void vhost_uninit_vmap(struct vhost_vmap *map) +{ + if (!map->addr) + return; + + vunmap(map->addr); + release_pages(map->pages, map->npages); + kfree(map->pages); + + map->addr = NULL; + map->pages = NULL; + map...