From: James Bottomley <James.Bottomley@SteelEye.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] make radix tree gang lookup faster by using a bitmap search
Date: Sun, 28 Aug 2005 22:26:34 -0500 [thread overview]
Message-ID: <1125285994.5048.40.camel@mulgrave> (raw)
In-Reply-To: <20050828183531.0b4d6f2d.akpm@osdl.org>
On Sun, 2005-08-28 at 18:35 -0700, Andrew Morton wrote:
> > Well ... It's my opinion (and purely unsubstantiated, I suppose) that
> > it's more efficient on 32 bit platforms to do bit operations on 32 bit
> > quantities, which is why I changed the radix tree map shift to 5 for
> > that case.
> >
> > It also makes much cleaner code than having to open code checks on
> > variable sized bitmaps.
> It does make the tree higher and hence will incur some more cache missing
> when descending the tree.
Actually, I don't think it does: the common user is the page tree.
Obviously, I've changed nothing on 64 bits, so we only need to consider
what I've done on 32 bits. A page size is almost universally 4k on 32
bit, so we need 20 bits to store the page tree index. Regardless of
whether the index size is 5 or 6, that gives a radix tree depth of 4.
> We changed the node size a few years back. umm....
> http://www.ussg.iu.edu/hypermail/linux/kernel/0206.2/0141.html
Yes, but that was to reduce the index size from 7 to 6 for slab
allocation reasons. I've just reduced it to 5 on 32 bit.
> It would be a little bit sad to be unable to make such tuning adjustments
> in the future. Not a huge loss, but a loss.
Well .. OK .. If the benchmarks say I've slowed us down on 32 bits, I'll
put the variable sizing back in the tag array.
James
next prev parent reply other threads:[~2005-08-29 3:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-27 16:26 [PATCH] make radix tree gang lookup faster by using a bitmap search James Bottomley
2005-08-27 17:53 ` Andrew Morton
2005-08-28 19:43 ` James Bottomley
2005-08-28 20:00 ` Linus Torvalds
2005-08-28 20:39 ` Andrew Morton
2005-08-29 0:45 ` James Bottomley
2005-08-29 0:52 ` Andrew Morton
2005-08-29 1:19 ` James Bottomley
2005-08-29 1:35 ` Andrew Morton
2005-08-29 3:26 ` James Bottomley [this message]
2005-08-29 3:37 ` Nick Piggin
2005-08-29 3:54 ` Trond Myklebust
2005-08-29 13:16 ` Luben Tuikov
2005-08-29 15:01 ` James Bottomley
[not found] ` <20050829164144.GC9508@localhost.localdomain>
2005-08-30 0:56 ` Nick Piggin
2005-08-30 1:54 ` Andrew Morton
2005-08-30 2:46 ` James Bottomley
2005-08-30 2:53 ` Nick Piggin
[not found] ` <20050830052405.GB20843@localhost.localdomain>
2005-08-30 13:06 ` Nick Piggin
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=1125285994.5048.40.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/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