From: Ryan Harper <ryanh@us.ibm.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH 0/6] xen,xend,tools: NUMA support for Xen
Date: Tue, 11 Jul 2006 20:23:13 -0500 [thread overview]
Message-ID: <20060712012313.GO1694@us.ibm.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D57206B@liverpoolst.ad.cl.cam.ac.uk>
* Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> [2006-07-11 16:28]:
> > > What sort of box are these numbers taken from? If it's not a NUMA
> > > system then the slowdowns are rather poor. We're particularly
> > > interested in not slowing down non-NUMA and small-NUMA (e.g., AMD
> K8)
> > > x86 systems. They are what we really want to see measurements from.
> >
> > The measurements are taken from a two-way Operton 248 (2.1Ghz) ,
> > small-NUMA. I agree that there is significant overhead, however, we
> > aren't talking about fast path here; correct me if I'm wrong. We
> > are only adding overhead to during domain startup. The end result
> > being we pay for local memory allocation at creation time while
> > benefiting from local memory access for the lifetime of the domain.
> >
> > I'm going to gather some oprofile data to see if I missed something
> > obvious, but in general I think that having local memory is of greater
> > benefit for the lifetime of a domain than the cost we incur during its
> > creation.
>
> What do the numbers look like on a 1 node system?
For K8 small numa, I don't have a 1 node system available.
>
> The shadow mode code potentially churns the page allocator a fair bit.
> It'll be disappointing if we have to add complexity of quicklists etc.
Yeah, I forgot about shadow mode; good point.
>
> It does kind of surprise me that the overhead is as high as you've
> measured. In the case where there's memory available in the favoured
> node I'd expect allocation performance to be very similar. 4 times
> slower and worsening for large allocations seems odd -- 0.3 microseconds
> a page is a bit more than I'd expect during back-to-back allocations.
> It's certainly worth trying to understand the overhead a bit more.
I agree. I'm a little mystified by the overhead as well. On the larger
system, ballooning up to 23G had something like 11% overhead, which was
more reasonable, though the domain creation tests showed more than 11%
on that system as well. I'll get the oprofile data and take a look.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
next prev parent reply other threads:[~2006-07-12 1:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 21:28 [PATCH 0/6] xen,xend,tools: NUMA support for Xen Ian Pratt
2006-07-12 1:23 ` Ryan Harper [this message]
2006-07-12 20:30 ` Ryan Harper
-- strict thread matches above, loose matches on Subject: below --
2006-07-11 16:40 Lu, Yinghai
2006-07-11 15:35 Ryan Harper
2006-07-11 15:57 ` Keir Fraser
2006-07-11 17:47 ` Ryan Harper
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=20060712012313.GO1694@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--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.