Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-23 Thread Roman Peniaev
On Fri, Apr 22, 2016 at 11:49 PM, Andrew Morton wrote: > On Fri, 15 Apr 2016 12:14:31 +0100 Chris Wilson > wrote: > >> > > purge_fragmented_blocks() manages per-cpu lists, so that looks safe >> > > under its own rcu_read_lock. >> > > >> > > Yes, it looks feasible to remove the purge_lock if we c

Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-22 Thread Andrew Morton
On Fri, 15 Apr 2016 12:14:31 +0100 Chris Wilson wrote: > > > purge_fragmented_blocks() manages per-cpu lists, so that looks safe > > > under its own rcu_read_lock. > > > > > > Yes, it looks feasible to remove the purge_lock if we can relax sync. > > > > what is still left is waiting on vmap_are

Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-15 Thread Chris Wilson
On Thu, Apr 14, 2016 at 04:44:48PM +0200, Roman Peniaev wrote: > On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson > wrote: > > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: > >> Hi, Chris. > >> > >> Is it made on purpose not to drop VM_LAZY_FREE flag in > >> __purge_vmap_area_lazy()

Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-14 Thread Roman Peniaev
On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson wrote: > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: >> Hi, Chris. >> >> Is it made on purpose not to drop VM_LAZY_FREE flag in >> __purge_vmap_area_lazy()? With your patch va->flags >> will have two bits set: VM_LAZY_FREE | VM_LAZY

Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-14 Thread Chris Wilson
On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: > Hi, Chris. > > Is it made on purpose not to drop VM_LAZY_FREE flag in > __purge_vmap_area_lazy()? With your patch va->flags > will have two bits set: VM_LAZY_FREE | VM_LAZY_FREEING. > Seems it is not that bad, because all other code

Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-14 Thread Roman Peniaev
Hi, Chris. Is it made on purpose not to drop VM_LAZY_FREE flag in __purge_vmap_area_lazy()? With your patch va->flags will have two bits set: VM_LAZY_FREE | VM_LAZY_FREEING. Seems it is not that bad, because all other code paths do not care, but still the change is not clear. Also, did you consi

[PATCH] mm/vmalloc: Keep a separate lazy-free list

2016-04-11 Thread Chris Wilson
When mixing lots of vmallocs and set_memory_*() (which calls vm_unmap_aliases()) I encountered situations where the performance degraded severely due to the walking of the entire vmap_area list each invocation. One simple improvement is to add the lazily freed vmap_area to a separate lockless free