home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] How good is Linux at NUMA ?

On Tue, 2006-03-28 at 12:21 -0500, Martin Hicks wrote:
> On Tue, Mar 28, 2006 at 11:27:08AM -0500, Peter Sjoberg wrote:
> > I just wonder if anyone knows what state  the linux NUMA implementation
> > is at. I looked on some linux numa sites but it seems very dated (many
> > 2001 and 2004 the latest).
> > I had a discussion with a friend about how good numa is on linux and his
> > opinion is that we should run x86 Solaris on all opterons or replace the
> > 4way with UP system since numa is so immature under linux.
> 
> NUMA works quite well under Linux.  There is room for improvement,
> perhaps, but people like HP, AMD and SGI all have NUMA machines, and
> SGI's are even Linux *only* (and they're actually the biggest computers
> too, with up to 1024CPUs in a single machine)
I'm interested in how far it goes. As I understand it you have some
stickiness when it comes to process cpu but don't know how strong it is.
If a process starts to access a file, are the cache buffers allocated
randomly or going to the same cpu(socket). Is memory migration planned?
I seen some talk about making it more aware about near -far-farther
memory, and make it work better with multi-core and multi threading.
Solaris has implemented at least some of it in the latest version (to
work better with there 8 core 32 thread cpu). 
Where does Linux kernel stand on this?
Where is the best place to ask this questions? Didn't see linux-numa and
in linux-kernel with 300+ mails/day is more then I handle.

> 
> There is libNUMA to do manual intervention on how you want memory
> policies to be inforced (local first, round robin, local only) as well
> as assigning jobs to run on certain CPUs.
Guess that works for program written for it but what about normal
cases. 
I have an almost hypothetical case with 4 cpu/memory hogging  java
processes running on a 4way opteron. Almost since the case exist but
they run Redhat 4 -32bit so the OS can't handle numa and they aren't
interested in moving to -64bit(yet).

> 
> mh
>