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

From	zhouxianrong <zhouxianrong@huawei.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH vmalloc] reduce purge_lock range and hold time of
Date	2016-10-18 05:00 +0200
Message-ID	<stsNc-4eA-9@gated-at.bofh.it> (permalink)
References	<ssy8i-nb-5@gated-at.bofh.it> <ssAtr-1OK-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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, zhouxianrong@huawei.com wrote:
>> From: z00281421 <z00281421@notesmail.huawei.com>
>>
>> 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 loop times sometimes is larg and spend a few time.
>
> Right, see the previous patch in reply to Joel that drops purge_lock
> entirely.
>
> Instead of your open coded batch counter you probably want to add
> a cond_resched_lock after the call to __free_vmap_area.
>
> .
>

Thread

[PATCH vmalloc] reduce purge_lock range and hold time of <zhouxianrong@huawei.com> - 2016-10-15 16:30 +0200
  Re: [PATCH vmalloc] reduce purge_lock range and hold time of Christoph Hellwig <hch@infradead.org> - 2016-10-15 19:00 +0200
    Re: [PATCH vmalloc] reduce purge_lock range and hold time of zhouxianrong <zhouxianrong@huawei.com> - 2016-10-18 05:00 +0200
  [PATCH vmalloc] reduce purge_lock range and hold time of vmap_area_lock <zhouxianrong@huawei.com> - 2016-10-18 04:30 +0200

csiph-web