From: "Yin, Fengwei" <fengwei.yin@intel.com>
To: Hugh Dickins <hughd@google.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Peng Zhang <zhangpeng.00@bytedance.com>,
<maple-tree@lists.infradead.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
"Liu, Yujie" <yujie.liu@intel.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/14] Reduce preallocations for maple tree
Date: Tue, 6 Jun 2023 11:11:09 +0800 [thread overview]
Message-ID: <205e7eae-fb30-1464-447a-5d284417c603@intel.com> (raw)
In-Reply-To: <ff754a68-4f94-e818-a31f-c8a1fd11b4b5@google.com>
On 6/6/2023 11:08 AM, Hugh Dickins wrote:
> On Tue, 6 Jun 2023, Yin, Fengwei wrote:
>> 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.
>
> I was going to say:
> No, I did not mean that: I just meant that even developers not doing
> strict performance testing still like to keep a rough eye on performance
> changes; and historically CONFIG_DEBUG_VM has not distorted very much.
>
> But then I wonder about certain distros which (wrongly or rightly) turn
> CONFIG_DEBUG_VM on: I expect they do performance testing on their kernels.
Fair enough. Thanks for explanation.
Regards
Yin, Fengwei
>
> Hugh
next prev parent reply other threads:[~2023-06-06 3:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 2:15 Liam R. Howlett
2023-06-01 2:15 ` [PATCH 01/14] maple_tree: Add benchmarking for mas_for_each Liam R. Howlett
2023-06-01 2:15 ` [PATCH 02/14] maple_tree: Add benchmarking for mas_prev() Liam R. Howlett
2023-06-01 2:15 ` [PATCH 03/14] mm: Move unmap_vmas() declaration to internal header Liam R. Howlett
2023-06-01 2:15 ` [PATCH 04/14] mm: Change do_vmi_align_munmap() side tree index Liam R. Howlett
2023-06-01 2:15 ` [PATCH 05/14] mm: Remove prev check from do_vmi_align_munmap() Liam R. Howlett
2023-06-01 2:15 ` [PATCH 06/14] maple_tree: Introduce __mas_set_range() Liam R. Howlett
2023-06-01 2:15 ` [PATCH 07/14] mm: Remove re-walk from mmap_region() Liam R. Howlett
2023-06-01 2:15 ` [PATCH 08/14] maple_tree: Re-introduce entry to mas_preallocate() arguments Liam R. Howlett
2023-06-01 2:16 ` [PATCH 09/14] mm: Use vma_iter_clear_gfp() in nommu Liam R. Howlett
2023-06-01 2:16 ` [PATCH 10/14] mm: Set up vma iterator for vma_iter_prealloc() calls Liam R. Howlett
2023-06-01 2:16 ` [PATCH 11/14] maple_tree: Move mas_wr_end_piv() below mas_wr_extend_null() Liam R. Howlett
2023-06-01 2:16 ` [PATCH 12/14] maple_tree: Update mas_preallocate() testing Liam R. Howlett
2023-06-01 2:16 ` [PATCH 13/14] maple_tree: Refine mas_preallocate() node calculations Liam R. Howlett
2023-06-02 10:37 ` Peng Zhang
2023-06-02 18:53 ` Liam R. Howlett
2023-06-01 2:16 ` [PATCH 14/14] mm/mmap: Change vma iteration order in do_vmi_align_munmap() Liam R. Howlett
2023-06-02 8:10 ` [PATCH 00/14] Reduce preallocations for maple tree Yin, Fengwei
2023-06-02 18:55 ` Liam R. Howlett
2023-06-04 12:10 ` Yin, Fengwei
2023-06-05 3:28 ` Peng Zhang
2023-06-05 4:41 ` Yin Fengwei
2023-06-05 6:18 ` Yin, Fengwei
2023-06-05 7:59 ` Peng Zhang
2023-06-05 14:03 ` Liam R. Howlett
2023-06-05 14:27 ` Peng Zhang
2023-06-05 14:44 ` Liam R. Howlett
2023-06-05 15:06 ` Peng Zhang
2023-06-06 1:34 ` Yin Fengwei
2023-06-06 2:41 ` Hugh Dickins
2023-06-06 2:55 ` Yin, Fengwei
2023-06-06 3:08 ` Hugh Dickins
2023-06-06 3:11 ` Yin, Fengwei [this message]
2023-06-06 16:07 ` Liam R. Howlett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=205e7eae-fb30-1464-447a-5d284417c603@intel.com \
--to=fengwei.yin@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=yujie.liu@intel.com \
--cc=zhangpeng.00@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome