From: Nick Piggin <npiggin@suse.de>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cache last free vmap_area to avoid restarting beginning
Date: Mon, 24 May 2010 16:23:48 +1000 [thread overview]
Message-ID: <20100524062347.GS2516@laptop> (raw)
In-Reply-To: <1274522033.1953.21.camel@barrios-desktop>
On Sat, May 22, 2010 at 06:53:53PM +0900, Minchan Kim wrote:
> Hi, Nick.
> Sorry for late review.
No problem, thanks for reviewing.
> On Thu, 2010-05-06 at 02:16 +1000, Nick Piggin wrote:
> > On Wed, May 05, 2010 at 01:48:48PM +0100, Steven Whitehouse wrote:
> > @@ -348,11 +354,23 @@ retry:
> > if (addr + size - 1 < addr)
> > goto overflow;
> >
> > - /* XXX: could have a last_hole cache */
> > - n = vmap_area_root.rb_node;
> > - if (n) {
> > - struct vmap_area *first = NULL;
> > + if (size <= cached_hole_size || addr < cached_start || !free_vmap_cache) {
>
> Do we need !free_vmap_cache check?
> In __free_vmap_area, we already reset whole of variables when free_vmap_cache = NULL.
You're right.
> > + cached_hole_size = 0;
> > + cached_start = addr;
> > + free_vmap_cache = NULL;
> > + }
> >
> > + /* find starting point for our search */
> > + if (free_vmap_cache) {
> > + first = rb_entry(free_vmap_cache, struct vmap_area, rb_node);
> > + addr = ALIGN(first->va_end + PAGE_SIZE, align);
> > +
> > + } else {
> > + n = vmap_area_root.rb_node;
> > + if (!n)
> > + goto found;
> > +
> > + first = NULL;
> > do {
> > struct vmap_area *tmp;
> > tmp = rb_entry(n, struct vmap_area, rb_node);
> > @@ -369,26 +387,36 @@ retry:
> > if (!first)
> > goto found;
> >
> > - if (first->va_end < addr) {
> > + if (first->va_start < addr) {
>
> I can't understand your intention.
> Why do you change va_end with va_start?
Because we don't want an area which is spanning the start address. And
it makes subsequent logic simpler.
> > + BUG_ON(first->va_end < addr);
>
> And Why do you put this BUG_ON in here?
> Could you elaborate on logic?
It seems this is wrong, so I've removed it. This is the BUG that
Steven hit, but there is another bug in there that my stress tester
wasn't triggering.
>
> > n = rb_next(&first->rb_node);
> > + addr = ALIGN(first->va_end + PAGE_SIZE, align);
> > if (n)
> > first = rb_entry(n, struct vmap_area, rb_node);
> > else
> > goto found;
> > }
> > + BUG_ON(first->va_start < addr);
>
> Ditto.
Don't want an area spanning start address, as above.
> > rb_erase(&va->rb_node, &vmap_area_root);
> > RB_CLEAR_NODE(&va->rb_node);
> > list_del_rcu(&va->list);
>
> Hmm. I will send refactoring version soon.
> If you don't mind, let's discuss in there. :)
I just reworked the initial patch a little bit and fixed a bug in it,
if we could instead do the refactoring on top of it, that would save
me having to rediff?
I'll post it shortly.
Thanks,
Nick
--
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 prev parent reply other threads:[~2010-05-24 6:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-12 16:27 vmalloc performance Steven Whitehouse
2010-04-14 12:49 ` Steven Whitehouse
2010-04-14 14:24 ` Steven Whitehouse
2010-04-14 15:12 ` Minchan Kim
2010-04-14 15:13 ` Minchan Kim
2010-04-14 16:35 ` Minchan Kim
2010-04-15 8:33 ` Steven Whitehouse
2010-04-15 16:51 ` Minchan Kim
2010-04-16 14:10 ` Steven Whitehouse
2010-04-18 15:14 ` Minchan Kim
2010-04-19 12:58 ` Steven Whitehouse
2010-04-19 14:12 ` Minchan Kim
2010-04-29 13:43 ` Steven Whitehouse
2010-05-02 17:29 ` [PATCH] cache last free vmap_area to avoid restarting beginning Minchan Kim
2010-05-05 12:48 ` Steven Whitehouse
2010-05-05 16:16 ` Nick Piggin
2010-05-17 12:42 ` Steven Whitehouse
2010-05-18 13:44 ` Steven Whitehouse
2010-05-19 13:54 ` Steven Whitehouse
2010-05-19 13:56 ` Nick Piggin
2010-05-25 8:43 ` Nick Piggin
2010-05-25 15:00 ` Minchan Kim
2010-05-25 15:48 ` Steven Whitehouse
2010-05-22 9:53 ` Minchan Kim
2010-05-24 6:23 ` Nick Piggin [this message]
2010-04-19 13:38 ` vmalloc performance Nick Piggin
2010-04-19 14:09 ` Minchan Kim
2010-04-16 6:12 ` Nick Piggin
2010-04-16 7:20 ` Minchan Kim
2010-04-16 8:50 ` Steven Whitehouse
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=20100524062347.GS2516@laptop \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.com \
--cc=swhiteho@redhat.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).