All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@novell.com>
Subject: RE: Update radix-tree.[ch] from upstream Linux to gain RCU awareness.
Date: Wed, 11 May 2011 15:12:02 -0700 (PDT)	[thread overview]
Message-ID: <ad2aeb0a-a290-4a4f-a822-963e59d0df86@default> (raw)
In-Reply-To: <C9F0C2CC.1A2CC%keir.xen@gmail.com>

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Update radix-tree.[ch] from upstream Linux to gain RCU
> awareness.
> 
> On 11/05/2011 21:38, "Dan Magenheimer" <dan.magenheimer@oracle.com>
> wrote:
> 
> > I'm not sure the height=0 special-casing is pointless.  IIRC, a
> > radix-tree node contains 64 pointers (512 bytes).  When trees
> containing
> > a single item are common, 512 bytes may be a relatively large
> overhead
> > For tmem, each tree contains pages from a file, many files on
> > many filesystems are less than one-page, and, when compressed that
> > one page may be represented by far less than 4096 bytes, so avoiding
> > the overhead is a big win.
> >
> > While I like your improvements avoiding the extra args passed on each
> > insert/delete, I'm not sure for tmem the tradeoff is a good one.
> > A basic assumption of tmem is that memory is constrained and
> > CPU cycles are abundant.  While we've all been trained to avoid
> > passing parameters when possible to reduce CPU overhead,
> > the world is changing.  If radix-tree.c is used in Xen in the future
> > for non-tmem high-frequency inserts/deletes, your CPU optimization
> > is probably best, but for tmem I think it's a net loss as now
> > each radix tree (and there may be thousands or millions in a
> > large tmem-enabled Xen system) "wastes" 24 bytes.
> 
> If this is critical, you simply shouldn't represent such small files
> with a
> radix tree. I'm sure you could easily come up with some scheme to
> switch to
> a single direct reference in the <= 1 page case, thus saving a whole
> radix_tree_root structure (and a radix_tree_node structure if I do kill
> the
> height=0 special case). I'd recommend changing the radix_tree_root
> inlined
> structure in tmem_object_root into a pointer which points at a
> radix_tree_root or a singleton page, discriminating between these two
> cases
> perhaps on pgp_count.

True, the special casing could be handled in tmem.  (On the chance
that you decide to do this, the special case only applies if
the pgp_count is 1 AND the index of the page is zero.)  Note
also that tmem doesn't have a clue about the size of the file
and may frequently need to change between an object that only
has page index==0 in tmem and one that has more than that.
The net result is that you would simply be moving the special
casing and "automatic transformation" code from radix-tree to
tmem, for a net result of no advantage (AFAICT) and IMHO since
the code needs to be somewhere, it might as well be in radix-tree
since it is already there and debugged for Linux.

      reply	other threads:[~2011-05-11 22:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1QK0HT-0006Nb-FM@xenbits.xen.org>
2011-05-11 20:38 ` Update radix-tree.[ch] from upstream Linux to gain RCU awareness Dan Magenheimer
2011-05-11 21:48   ` Keir Fraser
2011-05-11 22:12     ` Dan Magenheimer [this message]

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=ad2aeb0a-a290-4a4f-a822-963e59d0df86@default \
    --to=dan.magenheimer@oracle.com \
    --cc=JBeulich@novell.com \
    --cc=keir.xen@gmail.com \
    --cc=xen-devel@lists.xensource.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.