On Mon, 2005-07-11 at 11:02 -0700, Christoph Lameter wrote: > On Mon, 11 Jul 2005, Dave Hansen wrote: > > > So, if something like numa_maps existed, but pointed to the memory > > object instead of the NUMA node directly, you could still easily derive > > the NUMA node. But, you'd also get information about which particular > > bits of memory are being used. That might be useful for a user that's > > getting desperate to remove some memory and wants to kill some processes > > that might be less than willing to release that memory. > > We really need both I guess. If you dealing with a batch scheduler that > wants to move memory around between nodes in order to optimize programs > then you nedd to have numa_maps. Maybe we need to have two: numa_maps > and memory_maps?
Well, my point was that, if we have two, the numa_maps can be completely derived in userspace from the information in memory_maps plus sysfs alone. So, why increase the kernel's complexity with two implementations that can do the exact same thing? Yes, it might make the batch scheduler do one more pathname lookup, but that's not the kernel's problem :) BTW, are you planning on using SPARSEMEM whenever NUMA is enabled in the future? -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
