All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>,
	Nitin Kamble <nitin.a.kamble@intel.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [RFC] Handling of number of cores the guest sees
Date: Wed, 25 Aug 2010 14:06:36 +0200	[thread overview]
Message-ID: <4C75074C.1080202@amd.com> (raw)

Hi,

while experimenting with guest NUMA configurations I realized that Xen 
injects the host's core number into each guest.
I believe this behavior is wrong, the number of cores should somehow be 
dependent from the number of VCPUs.
Currently a CPUID decoding tool of mine gives me the following output 
for a 4 VCPU guest:
------------
HTT: 1, CmpLegacy: 1, LogicalProcessorCount: 24
AMD decoding:
         NC: 23, ApicIdCoreIdSize: 16
             24 cores   (legacy method)
          24/16 cores (extended method)
------------
(This is on a 12-core host CPU).
Applying my previous patch reduces the 24 to 12, but that still does not 
match the 4 VCPUs seen.
For proper NUMA functionality we need more sane values here, it seems 
that at least Linux does not care about the strange numbers as long as 
NUMA is not used. When a SRAT table is found, the guest kernel panics in 
the scheduler's rebalancer with those bogus numbers.

How shall we solve this issue? I see several ways:

1. Always inject one core per processor. SMP guests are then n-way, the 
CPUID setup is trivial and works well. But we may run into licensing 
issues, as some software (MS Windows comes to mind) is limited by the 
number of processors, but not by the number of cores.

2. Inject exactly the same number of cores as there are VCPUs. This 
could lead to potentially strange core numbers, but software should cope 
with this (as there are 3-core, 6-core and 12-cores processors).
This would lead to problems with a NUMA setup, though.

3. Let the user specify the number of cores in the config file. Needs 
user interaction and can lead to problems if it somehow conflicts the 
number of VCPUs. But would be nice to have as an additional tuning 
parameter. I could implement this.

4. Implement solution 2), but tune the behavior if guest NUMA is 
enabled. We could make sure that the number of cores is not bigger than 
the number of VCPUs on one NUMA node.

What approach shall I use? Are there other concerns regarding the 
CPUID's readout of the nubmer of cores?

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

             reply	other threads:[~2010-08-25 12:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-25 12:06 Andre Przywara [this message]
2010-08-25 12:43 ` [RFC] Handling of number of cores the guest sees Keir Fraser
2010-08-25 15:34 ` Huang2, Wei

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=4C75074C.1080202@amd.com \
    --to=andre.przywara@amd.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=nitin.a.kamble@intel.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.