linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Wei Yang <richardw.yang@linux.intel.com>,
	akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	yang.shi@linux.alibaba.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [RESEND [PATCH] 0/2] mm/mmap.c: reduce subtree gap propagation a little
Date: Wed, 28 Aug 2019 10:01:40 +0200	[thread overview]
Message-ID: <4503e006-76ba-ed06-0184-6e361a66ba88@suse.cz> (raw)
In-Reply-To: <20190828060614.19535-1-richardw.yang@linux.intel.com>

On 8/28/19 8:06 AM, Wei Yang wrote:
> When insert and delete a vma, it will compute and propagate related subtree
> gap. After some investigation, we can reduce subtree gap propagation a little.
> 
> [1]: This one reduce the propagation by update *next* gap after itself, since
>      *next* must be a parent in this case.
> [2]: This one achieve this by unlinking vma from list.
> 
> After applying these two patches, test shows it reduce 0.3% function call for
> vma_compute_subtree_gap.

BTW, what's the overall motivation of focusing so much
micro-optimization effort on the vma tree lately? This has been rather
stable code where we can be reasonably sure of all bugs being found. Now
even after some review effort, subtle bugs can be introduced. And
Matthew was warning for a while about an upcoming major rewrite of the
whole data structure, which will undo all this effort?

> BTW, this series is based on some un-merged cleanup patched.
> 
> ---
> This version is rebased on current linus tree, whose last commit is
> commit 9e8312f5e160 ("Merge tag 'nfs-for-5.3-3' of
> git://git.linux-nfs.org/projects/trondmy/linux-nfs").
> 
> Wei Yang (2):
>   mm/mmap.c: update *next* gap after itself
>   mm/mmap.c: unlink vma before rb_erase
> 
>  mm/mmap.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 



  parent reply	other threads:[~2019-08-28  8:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28  6:06 Wei Yang
2019-08-28  6:06 ` [RESEND [PATCH] 1/2] mm/mmap.c: update *next* gap after itself Wei Yang
2019-08-28  6:06 ` [RESEND [PATCH] 2/2] mm/mmap.c: unlink vma before rb_erase Wei Yang
2019-08-28  8:01 ` Vlastimil Babka [this message]
2019-08-28  8:27   ` [RESEND [PATCH] 0/2] mm/mmap.c: reduce subtree gap propagation a little Wei Yang
2019-12-23  3:05 ` Wei Yang

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=4503e006-76ba-ed06-0184-6e361a66ba88@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=willy@infradead.org \
    --cc=yang.shi@linux.alibaba.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