From: Simon D. <Sim...@bu...> - 2006-03-13 15:17:59
|
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 ? Simon. |
From: Paul E. M. <pa...@us...> - 2006-03-13 18:20:15
|
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 ? Some would argue that cpusets covers some of the functionality in #3. 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. Thanx, Paul |
From: Simon D. <Sim...@bu...> - 2006-03-15 12:53:54
|
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, multi-core CPUs... |