From: Andi Kleen <andi@firstfloor.org>
To: Avi Kivity <avi@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Andre Przywara <andre.przywara@amd.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 0/3] KVM-userspace: add NUMA support for guests
Date: Sat, 29 Nov 2008 21:10:32 +0100 [thread overview]
Message-ID: <20081129201032.GT6703@one.firstfloor.org> (raw)
In-Reply-To: <49318D57.6040601@redhat.com>
On Sat, Nov 29, 2008 at 08:43:35PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> >It depends -- it's not necessarily an improvement. e.g. if it leads to
> >some CPUs being idle while others are oversubscribed because of the
> >pinning you typically lose more than you win. In general default
> >pinning is a bad idea in my experience.
> >
> >Alternative more flexible strategies:
> >
> >- Do a mapping from CPU to node at runtime by using getcpu()
> >- Migrate to complete nodes using migrate_pages when qemu detects
> >node migration on the host.
> >
>
> Wouldn't that cause lots of migrations? Migrating a 1GB guest can take
I assume you mean the second one (the two points were orthogonal)
The first one is an approximate method, also has advantages
and disadvantages.
> a huge amount of cpu time (tens or even hundreds of milliseconds?)
> compared to very high frequency activity like the scheduler.
Yes migration is expensive, although you can do it on demand of course,
but the scheduler typically has pretty strong cpu affinity so it shouldn't
happen too often. Also it's only a temporary cost compared to the
endless overhead of running forever non local or running forever with
some cores idle.
Another strategy would be to tune the load balancer in the scheduler
for this case and make it only migrate in extreme situations.
Anyways it's not ideal either, but in my mind would be all preferable
to default CPU pinning.
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-11-29 19:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-27 22:23 [PATCH 0/3] KVM-userspace: add NUMA support for guests Andre Przywara
2008-11-28 8:14 ` Andi Kleen
2008-11-29 18:43 ` Avi Kivity
2008-11-29 20:10 ` Andi Kleen [this message]
2008-11-29 20:35 ` Avi Kivity
2008-11-30 15:41 ` Andi Kleen
2008-11-30 15:38 ` Avi Kivity
2008-11-30 16:05 ` Andi Kleen
2008-11-30 16:38 ` Avi Kivity
2008-11-30 17:04 ` Andi Kleen
2008-11-30 17:11 ` Avi Kivity
2008-11-30 17:42 ` Andi Kleen
2008-11-30 18:07 ` Avi Kivity
2008-11-30 18:55 ` Andi Kleen
2008-11-30 19:11 ` Skywing
2008-11-30 20:08 ` Avi Kivity
2008-11-30 20:07 ` Avi Kivity
2008-11-30 21:41 ` Andi Kleen
2008-11-30 21:50 ` Avi Kivity
2008-11-30 22:08 ` Skywing
2008-11-28 10:40 ` Daniel P. Berrange
2008-11-29 18:29 ` Avi Kivity
2008-12-01 14:15 ` Andre Przywara
2008-12-01 14:29 ` Avi Kivity
2008-12-01 15:27 ` Anthony Liguori
2008-12-01 15:34 ` Anthony Liguori
2008-12-01 15:37 ` Avi Kivity
2008-12-01 15:49 ` Anthony Liguori
2008-12-01 14:44 ` Daniel P. Berrange
2008-12-01 14:53 ` Avi Kivity
2008-12-01 15:18 ` Anthony Liguori
2008-12-01 15:35 ` Avi Kivity
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=20081129201032.GT6703@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=andre.przywara@amd.com \
--cc=avi@redhat.com \
--cc=kvm@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