From: Michel Lespinasse <walken@google.com>
To: riel@redhat.com, peterz@infradead.org, daniel.santos@pobox.com,
aarcange@redhat.com, dwmw2@infradead.org,
akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] augmented rbtree changes
Date: Mon, 23 Jul 2012 18:46:11 -0700 [thread overview]
Message-ID: <20120724014611.GA6974@google.com> (raw)
In-Reply-To: <1342787467-5493-1-git-send-email-walken@google.com>
On Fri, Jul 20, 2012 at 05:31:01AM -0700, Michel Lespinasse wrote:
> Patch 5 speeds up the augmented rbtree erase. Here again we use a tree
> rotation callback during rebalancing; however we also have to propagate
> the augmented node information above nodes being erased and/or stitched,
> and I haven't found a nice enough way to do that. So for now I am proposing
> the simple-stupid way of propagating all the way to the root. More on
> this later.
So, I looked at it again and finally figured out a decent way to avoid
unnecessary propagation here. Going to resend patches 5/6 as replies to
their original postings.
> - The prio tree of all VMAs mapping a given file (struct address_space)
> could be switched to an augmented rbtree based interval tree (thus removing
> the prio tree library in favor of augmented rbtrees)
I actually have a prototype for that already. The augmented rbtree based
implementation is slightly faster than prio tree on insert/erase, and
considerably faster on lookups. However, this is with a synthetic test
exercising prio and rbtrees directly, not with a realistic workload going
through the MM layers. Do we know of situations where prio tree performance
is currently a concern ?
> As they stand, patches 3-6 don't seem to make a difference for basic rbtree
> support, and they improve my augmented rbtree insertion/erase benchmark
> by a factor of ~2.1 to ~2.3 depending on test machines.
After rewriting patches 5-6 as discussed above, augmented rbtrees are now
~2.5 - ~2.7 times faster than before this patch series.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Michel Lespinasse <walken@google.com>
To: riel@redhat.com, peterz@infradead.org, daniel.santos@pobox.com,
aarcange@redhat.com, dwmw2@infradead.org,
akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] augmented rbtree changes
Date: Mon, 23 Jul 2012 18:46:11 -0700 [thread overview]
Message-ID: <20120724014611.GA6974@google.com> (raw)
In-Reply-To: <1342787467-5493-1-git-send-email-walken@google.com>
On Fri, Jul 20, 2012 at 05:31:01AM -0700, Michel Lespinasse wrote:
> Patch 5 speeds up the augmented rbtree erase. Here again we use a tree
> rotation callback during rebalancing; however we also have to propagate
> the augmented node information above nodes being erased and/or stitched,
> and I haven't found a nice enough way to do that. So for now I am proposing
> the simple-stupid way of propagating all the way to the root. More on
> this later.
So, I looked at it again and finally figured out a decent way to avoid
unnecessary propagation here. Going to resend patches 5/6 as replies to
their original postings.
> - The prio tree of all VMAs mapping a given file (struct address_space)
> could be switched to an augmented rbtree based interval tree (thus removing
> the prio tree library in favor of augmented rbtrees)
I actually have a prototype for that already. The augmented rbtree based
implementation is slightly faster than prio tree on insert/erase, and
considerably faster on lookups. However, this is with a synthetic test
exercising prio and rbtrees directly, not with a realistic workload going
through the MM layers. Do we know of situations where prio tree performance
is currently a concern ?
> As they stand, patches 3-6 don't seem to make a difference for basic rbtree
> support, and they improve my augmented rbtree insertion/erase benchmark
> by a factor of ~2.1 to ~2.3 depending on test machines.
After rewriting patches 5-6 as discussed above, augmented rbtrees are now
~2.5 - ~2.7 times faster than before this patch series.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
next prev parent reply other threads:[~2012-07-24 1:46 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 12:31 [RFC PATCH 0/6] augmented rbtree changes Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-20 12:31 ` [PATCH 1/6] rbtree: rb_erase updates and comments Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-24 18:50 ` Rik van Riel
2012-07-24 18:50 ` Rik van Riel
2012-07-20 12:31 ` [PATCH 2/6] rbtree: optimize fetching of sibling node Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-24 21:52 ` Rik van Riel
2012-07-24 21:52 ` Rik van Riel
2012-07-20 12:31 ` [PATCH 3/6] augmented rbtree test Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-25 15:42 ` Rik van Riel
2012-07-25 15:42 ` Rik van Riel
2012-07-20 12:31 ` [PATCH 4/6] rbtree: faster augmented insert Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-25 16:10 ` Rik van Riel
2012-07-25 16:10 ` Rik van Riel
2012-07-25 17:54 ` Rik van Riel
2012-07-25 17:54 ` Rik van Riel
2012-07-27 19:26 ` Peter Zijlstra
2012-07-27 19:26 ` Peter Zijlstra
2012-07-27 21:43 ` Michel Lespinasse
2012-07-27 21:43 ` Michel Lespinasse
2012-07-27 19:31 ` Peter Zijlstra
2012-07-27 19:31 ` Peter Zijlstra
2012-07-27 20:04 ` Peter Zijlstra
2012-07-27 20:04 ` Peter Zijlstra
2012-07-27 21:55 ` Michel Lespinasse
2012-07-27 21:55 ` Michel Lespinasse
2012-07-20 12:31 ` [PATCH 5/6] rbtree: faster augmented erase Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-24 1:54 ` Michel Lespinasse
2012-07-24 1:54 ` Michel Lespinasse
2012-07-25 17:53 ` Rik van Riel
2012-07-25 17:53 ` Rik van Riel
2012-07-27 19:43 ` Peter Zijlstra
2012-07-27 19:43 ` Peter Zijlstra
2012-07-27 20:02 ` Peter Zijlstra
2012-07-27 20:02 ` Peter Zijlstra
2012-07-28 0:44 ` Michel Lespinasse
2012-07-28 0:44 ` Michel Lespinasse
2012-07-28 2:31 ` Michel Lespinasse
2012-07-28 2:31 ` Michel Lespinasse
2012-07-20 12:31 ` [PATCH 6/6] rbtree: remove prior augmented rbtree implementation Michel Lespinasse
2012-07-20 12:31 ` Michel Lespinasse
2012-07-24 1:55 ` Michel Lespinasse
2012-07-24 1:55 ` Michel Lespinasse
2012-07-25 17:59 ` Rik van Riel
2012-07-25 17:59 ` Rik van Riel
2012-07-24 1:46 ` Michel Lespinasse [this message]
2012-07-24 1:46 ` [RFC PATCH 0/6] augmented rbtree changes Michel Lespinasse
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=20120724014611.GA6974@google.com \
--to=walken@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=daniel.santos@pobox.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=riel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.