On Mon, 13 Mar 2006, Paul E. McKenney wrote:
> On Mon, Mar 13, 2006 at 04:17:19PM +0100, Simon Derr wrote:
> > Hi,
> > I was reading the minutes of a 'Linux-on-NUMA' meeting of March 2001 (I
> > feel a bit like an archaeologist) and this catched my eye:
> > "Subsequent discussion divided NUMA functionality into three groups:
> > (1) changes to improve performance on NUMA for non-NUMA-aware applications,
> > (2) changes to provide simple control of resources and execution as would
> > be needed for benchmarks and the like, and
> > (3) changes to allow more general and declarative control of resources and execution.
> > It would be very nice if the APIs for #2 were a nice subset of those for #3."
> > (http://lse.sourceforge.net/numa/older_stuff/meetings/mtg.2001.03.26/minutes.html)
> > I think we can say that many kernel-level improvements that have been
> > added since then cover group #1.
> > sys_schedsetaffinity(), libnuma and cpusets cover group #2.
> > And what about group #3 ?
> > Is anyone aware of ongoing work in that direction ?
Thanks for your reply.
> Some would argue that cpusets covers some of the functionality in #3.
I think that cpusets are really helpful for running efficiently
applications that were designed for SMP systems.
But I feel something is missing for an application that would be
numa-aware and that would try to use efficiently memory/cpus from several
nodes. An application could for instance have a way to describe how it is
going to use its memory : this memory block will be used only by a single
CPU, this one by 2 CPUs, this other block by all CPUs and the last will be
used for I/O.
> One important step would be to check up on what the performance and
> usability benefits of #3 would be. Today's NUMA machines are much
> "flatter" than were a number of the mid-90s machines, so the mileage
> one could expect to get from advanced NUMA-support functionality may
> well have changed.
OK, layers are flatter. But new layers are appearing: multi-threading,