From: Hugh Dickins <hughd@google.com>
To: "Yin, Fengwei" <fengwei.yin@intel.com>
Cc: Hugh Dickins <hughd@google.com>,
"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: Mon, 5 Jun 2023 20:08:56 -0700 (PDT) [thread overview]
Message-ID: <ff754a68-4f94-e818-a31f-c8a1fd11b4b5@google.com> (raw)
In-Reply-To: <d4d7157d-1e5b-fc7e-34de-66def46a344c@intel.com>
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.
Hugh
next prev parent reply other threads:[~2023-06-06 3:09 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 [this message]
2023-06-06 3:11 ` Yin, Fengwei
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=ff754a68-4f94-e818-a31f-c8a1fd11b4b5@google.com \
--to=hughd@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=fengwei.yin@intel.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