All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Ryan Harper <ryanh@us.ibm.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Ryan Grimm <grimm@us.ibm.com>
Subject: Re: Re: [PATCH 1/6][RESEND] xen: Add NUMA support to Xen
Date: Mon, 15 May 2006 19:25:38 +0200	[thread overview]
Message-ID: <200605151925.38968.ak@suse.de> (raw)
In-Reply-To: <398b24ac6e2efe186405c7014f89bbd5@cl.cam.ac.uk>

On Monday 15 May 2006 19:17, Keir Fraser wrote:
> 
> On 15 May 2006, at 18:11, Ryan Harper wrote:
> 
> > When I looked at the x86_64 NUMA code, I noticed that SRAT parsing was
> > done by ACPI_NUMA (drivers/acpi/numa.c).  That code requires more ACPI
> > support than Xen currently has available.  Rather than pulling in all 
> > of
> > that ACPI, I chose to start with the i386 SRAT table parser which was
> > sufficient for both i386 and x86_64.  I would think that using the
> > modified i386 srat.c for parser gets the job done without bringing in
> > all of the support needed to compile drivers/acpi/numa.c in Xen.
> >
> > How about putting the two together: use the i386 SRAT parser and the
> > x86_64 srat.c for structures and initialization?
> 
> I guess it depends how cleanly it can be done. Can we use the x86/64 
> logic pretty much unmodified, but then pull in bits of the i386 parsing 
> code as functions that the x86/64 code calls rather than the full-blown 
> acpi routines it would usually call into? Or would it be possible to 
> pull in drivers/acpi/numa.c 

Yes it should be. numa parsing doesn't need the interpreter. It only
reads a few tables from memory. You could probably even recode it easily to just
call the callbacks in srat.c after looking for the tables in memory.

Bigger issue might be to make it fully 32bit clean. But probably just a few
long -> long long should be enough. 

One reason the i386 NUMA code is so ugly that limited 32bit address spaces 
and NUMA really don't love each other regarding ZONE_NORMAL handling.
The i386 code has some nasty hacks to work around that, like these
memory chunks. The result was always poor of course because NUMA
essentially didn't apply to any kernel objects.

I guess in Xen that might be a bit easier from simpler zone setup (?) 

Or if all fails limit NUMA again to 
64bit hypervisors where it is much cleaner (AFAIK except for the old x440 
and NUMAQ everything  x86 doing NUMA is 64bit  capable) 

-Andi

  parent reply	other threads:[~2006-05-15 17:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-01 21:56 [PATCH 1/6] xen: Add NUMA support to Xen Ryan Harper
2006-05-02 14:15 ` Keir Fraser
2006-05-02 14:39   ` Ryan Harper
2006-05-12 15:12   ` [PATCH 1/6][RESEND] " Ryan Harper
2006-05-13  9:07     ` Keir Fraser
2006-05-15 16:27       ` Andi Kleen
2006-05-15 16:54         ` Keir Fraser
2006-05-15 17:11           ` Ryan Harper
2006-05-15 17:17             ` Keir Fraser
2006-05-15 17:23               ` Keir Fraser
2006-05-15 17:25               ` Andi Kleen [this message]
2006-05-15 17:27               ` Ryan Harper
2006-05-15 17:34                 ` Keir Fraser
2006-05-15 20:32                   ` Ryan Harper
2006-05-15 20:46                     ` Andi Kleen
2006-05-16  7:49                       ` Keir Fraser
2006-05-16 12:57                         ` Andi Kleen
2006-05-16 13:03                           ` Keir Fraser
2006-05-19 21:08                             ` Ryan Harper
2006-05-20  8:50                               ` Keir Fraser
2006-05-22 11:01                               ` Andi Kleen
2006-05-24 19:02                                 ` Ryan Harper
2006-05-31 18:06                                   ` Ryan Harper
2006-06-02 15:55                                     ` Ryan Harper
2006-05-17 17:21                         ` Ryan Harper
2006-05-17 18:07                           ` Andi Kleen
2006-05-18 15:30                             ` 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=200605151925.38968.ak@suse.de \
    --to=ak@suse.de \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=grimm@us.ibm.com \
    --cc=ryanh@us.ibm.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.