public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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