From: Hugh Dickins <hugh@veritas.com>
To: Daniel Lowengrub <lowdanie@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2.6.28 1/2] memory: improve find_vma
Date: Thu, 22 Jan 2009 17:22:39 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0901221658550.14302@blonde.anvils> (raw)
In-Reply-To: <8c5a844a0901220851g1c21169al4452825564487b9a@mail.gmail.com>
On Thu, 22 Jan 2009, Daniel Lowengrub wrote:
> The goal of this patch is to improve the efficiency of the find_vma
> function in mm/mmap.c. The function first checks whether the vma
> stored in the cache is the one it's looking for. Currently, it's
> possible for the cache to be correct and still get rejected because
> the function checks whether the given address is inside the vma in the
> cache, not whether the cached vma is the smallest one that's bigger
> than the address. To solve this problem I turned the list of vma's
> into a doubly linked list, and using that list made a function that
> can check if a given vma is the one that find_vma is looking for.
> This gives a greater number of cache hits than the standerd method.
> The doubly linked list can be used to optimize other parts of the
> memory management as well. I'll implement some of those possibilities
> in the next patch.
> Signed-off-by: Daniel Lowengrub <lowdanie@gmail.com>
Do you have some performance figures to support this patch?
Some of the lmbench tests may be appropriate.
The thing is, expanding vm_area_struct to include another pointer
will have its own cost, which may well outweigh the efficiency
(in one particular case) which you're adding. Expanding mm_struct
for this would be much more palatable, but I don't think that flies.
And it seems a little greedy to require both an rbtree and a doubly
linked list for working our way around the vmas.
I suspect that originally your enhancement would only have hit when
extending the stack: which I guess isn't enough to justify the cost.
But it could well be that unmapped area handling has grown more
complex down the years, and you get some hits now from that.
You mention using the doubly linked list to optimize some other parts
of mm too: I guess those interfaces where we have to pass around prev
would be simplified, are you thinking of those, or something else?
(I don't think we need unmap_vmas to go backwards!)
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next parent reply other threads:[~2009-01-22 17:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8c5a844a0901220851g1c21169al4452825564487b9a@mail.gmail.com>
2009-01-22 17:22 ` Hugh Dickins [this message]
2009-01-22 23:00 ` [PATCH 2.6.28 1/2] memory: improve find_vma Daniel Lowengrub
2009-01-22 23:13 ` Ingo Molnar
2009-01-23 11:10 ` Daniel Lowengrub
2009-01-28 21:31 ` Daniel Lowengrub
2009-01-29 14:19 ` Ingo Molnar
2009-02-01 11:19 ` Daniel Lowengrub
2009-02-01 13:00 ` Ingo Molnar
2009-02-05 11:26 ` Daniel Lowengrub
2009-02-05 19:41 ` Ingo Molnar
2009-02-05 19:51 ` Peter Zijlstra
2009-01-17 17:12 Daniel Lowengrub
2009-01-18 22:36 ` KOSAKI Motohiro
2009-01-20 16:26 ` Daniel Lowengrub
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=Pine.LNX.4.64.0901221658550.14302@blonde.anvils \
--to=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lowdanie@gmail.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;
as well as URLs for NNTP newsgroup(s).