Messages in this thread | | | Date | Mon, 28 Oct 2002 08:57:21 -0800 | From | "Martin J. Bligh" <> | Subject | Re: NUMA scheduler (was: 2.5 merge candidate list 1.5) |
| |
> The pool data is needed to be able to loop over the CPUs of one node, > only. I'm convinced we'll need to do that sometime, no matter how simple > the core of the NUMA scheduler is.
Hmmm ... is using node_to_cpumask from the topology stuff, then looping over that bitmask insufficient?
> The pool_lock is protecting that data while it is built. This can happen > in future more often, if somebody starts hotplugging CPUs.
Heh .... when someone actually does that, we'll have a lot more problems than just this to solve. Would be nice to keep this stuff simple for now, if possible.
> Sorry, the comment came from a former version...
No problem, I suspected that was all it was. >> just block). If you really still need to do this, RCU is now >> in the kernel ;-) If not, can we just chuck all that stuff? > > I'm preparing a core patch which doesn't need the pool_lock. I'll send it > out today.
Cool! Thanks,
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |