[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d4d7157d-1e5b-fc7e-34de-66def46a344c@intel.com>
Date: Tue, 6 Jun 2023 10:55:24 +0800
From: "Yin, Fengwei" <fengwei.yin@...el.com>
To: Hugh Dickins <hughd@...gle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Peng Zhang <zhangpeng.00@...edance.com>,
<maple-tree@...ts.infradead.org>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, "Liu, Yujie" <yujie.liu@...el.com>,
"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/14] Reduce preallocations for maple tree
Hi Huge,
On 6/6/2023 10:41 AM, Hugh Dickins wrote:
> On Mon, 5 Jun 2023, Liam R. Howlett wrote:
>>
>> You mean "mm: update validate_mm() to use vma iterator" here I guess. I
>> have it as a different commit id in my branch.
>>
>> I 'restored' some of the checking because I was able to work around not
>> having the mt_dump() definition with the vma iterator. I'm now
>> wondering how wide spread CONFIG_DEBUG_VM is used and if I should not
>> have added these extra checks.
>
> Most CONFIG_DEBUG_VM checks are quite cheap, mostly VM_BUG_ONs for
Indeed. I had CONFIG_DEBUG_VM enabled and didn't see surprise perf report.
> easily checked conditions. If validate_mm() is still the kind of thing
> it used to be, checking through every vma on every mmap operation, please
> don't bring that into CONFIG_DEBUG_VM - it distorts performance too much,
> so always used to be under a separate CONFIG_DEBUG_VM_RB instead.
So does this mean CONFIG_DEBUG_VM is allowed to be enabled for performance
testing? Thanks.
Regards
Yin, Fengwei
>
> Hugh
Powered by blists - more mailing lists