xen-devel.lists.xenproject.org archive mirror
 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 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).