From: Andre Przywara <andre.przywara@amd.com>
To: "Cui, Dexuan" <dexuan.cui@intel.com>, Dulloor <dulloor@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: NUMA guest PV enlightenment (was Re:[PATCH 00/11] PV NUMA Guests)
Date: Fri, 23 Apr 2010 14:45:38 +0200 [thread overview]
Message-ID: <4BD19672.60202@amd.com> (raw)
Hi,
(sorry for the late reply, the mail was already scrolled out of the
window ;-). I will split the thread up to allow quicker and more focused
responses).
Cui, Dexuan wrote:
> Dulloor wrote:
> ...
> Hi Dulloor,
> In your patches, the toolstack tries to figure out the "best fit
> nodes" for a PV guest and invokes a hypercall set_domain_numa_layout
> to tell the hypervisor to remember the info, and later the PV guest
> invokes a hypercall get_domain_numa_layout to retrieve the info from
> the hypervisor.
> Can this be changed to: the toolstack writes the guest numa info
> directly into a new field in the start_info(or the share_info) (maybe
> in the starndard format of the SRAT/SLIT) and later PV guest reads the
> info and uses acpi_numa_init() to parse the info? I think in this way
> the new hypercalls can be avoided and the pv numa enlightenment code
> in guest kernel can be minimized.
> I'm asking this because this is the way how HVM numa patches of
> Andure do(the toolstack passes the info to hvmloader and the latter
> builds SRAT/SLIT for guest)
I think that is a fundamental difference between PV and HVM, where in
HVM you naturally have to inject all infos, but PV is mostly querying
the info it needs. AFAICS the design of PV Linux is to remove everything
that is not absolutely necessary. I once also tried PV NUMA support, but
gave up when I discovered that both NUMA and ACPI were turned off in the
then-recent PV kernels (read: kudos to Dulloor ;-). I like the ELF hint
trick, it solves a big problem we have with HVM guests: Are they NUMA
aware or not? If not, the striping is maybe a better option than
persisting on the NUMA layout. Only for HVM guests it is almost
impossible to know beforehand.
So as far as this goes, I am OK with PV guests using hypercalls to query
the NUMA information, the only thing I would hint is to leverage the
already existing guest NUMA code and actually provide the info in ACPI
SRAT/SLIT format.
But one has to consider possible runtime changes to the topology, as
this is something that ACPI currently does not provide.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12
reply other threads:[~2010-04-23 12:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4BD19672.60202@amd.com \
--to=andre.przywara@amd.com \
--cc=dexuan.cui@intel.com \
--cc=dulloor@gmail.com \
--cc=jun.nakajima@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.