mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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