From: Andrea A. <an...@su...> - 2002-08-28 15:42:24
|
On Wed, Aug 28, 2002 at 08:25:15AM -0700, Martin J. Bligh wrote: > >> We're currently running the node affine NUMA scheduler on a 32 CPU > >> Itanium2 with 8 nodes and 2 supernodes and seeing benefits of the > >> multi-hierarchy features. But the scheduler just knows about the nodes > >> and their "distances" (memory access latency ratios), supernodes are > >> not used directly. The number of hierarchy levels is "discovered" from > >> the distances and used only during the setup phase. > > > > I see the point for the scheduler (and may even need it myself in future) > > But I don't think it makes sense to complicate the NUMA API just because > > the scheduler has more extensive requirements than everybody else. > > Better is probably to use a load balancer hook for this that is architecture > > specific and can tune the scheduler for your box. I think Robert Love posted > > a patch for this recently on l-k. > > Having every architecture implement its own scheduler code seems > like a lot of rework to me (that people are likely to screw up). that's not necessary. you can have a fallback library code enabled by a CONFIG_NUMA_SCHEDULER and archs with holes in the middle of the nodes can implement their own special arch code instead. All numa archs I work with doesn't have holes in the middle of the nodes of course so any abstraction on top of the nodes would be superflous. Furthmore I think it's flawed to put memory caming from the same numa node in two different pgdat just because there's an hole in the middle of the node. You should definitely use nonlinear from Daniel instead. The only case were nonlinear is useful is when there is an hole in the middle of the numa nodes. The reason I opposed so strongly to nonlinear originally is of course that I never heard of any arch with holes in the middle of the nodes before, but apparently somebody is apparently doing that kind of hardware for unknown reasons ;(. The scheduler hooks are the best way to deal with these issues because they don't force you on a API that may not be flexible enough for your lowlevel needs, and all normal numas will take advantage of the strightforward library code with no code replication. Andrea |