Re: [PATCH vmalloc] reduce purge_lock range and hold time of

2016-10-17 Thread zhouxianrong
hey Hellwig: cond_resched_lock is a good choice. i mixed the cond_resched_lock and batch to balance of realtime and performance and resubmit this patch. On 2016/10/16 0:55, Christoph Hellwig wrote: On Sat, Oct 15, 2016 at 10:12:48PM +0800, zhouxianr...@huawei.com wrote: From: z00281421

[PATCH vmalloc] reduce purge_lock range and hold time of vmap_area_lock

2016-10-17 Thread zhouxianrong
From: z00281421 Signed-off-by: z00281421 --- mm/vmalloc.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 91f44e7..e9c9c04 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -661,13 +661,18 @@ static void __purge_vmap_area_lazy(uns

Re: [PATCH vmalloc] reduce purge_lock range and hold time of

2016-10-15 Thread Christoph Hellwig
On Sat, Oct 15, 2016 at 10:12:48PM +0800, zhouxianr...@huawei.com wrote: > From: z00281421 > > i think no need to place __free_vmap_area loop in purge_lock; > _free_vmap_area could be non-atomic operations with flushing tlb > but must be done after flush tlb. and the whole__free_vmap_area loops >

[PATCH vmalloc] reduce purge_lock range and hold time of

2016-10-15 Thread zhouxianrong
From: z00281421 i think no need to place __free_vmap_area loop in purge_lock; _free_vmap_area could be non-atomic operations with flushing tlb but must be done after flush tlb. and the whole__free_vmap_area loops also could be non-atomic operations. if so we could improve realtime because the loo