From: Brian S. <bl...@sg...> - 2004-09-03 18:39:59
|
"Martin J. Bligh" wrote: > > > "Martin J. Bligh" wrote: > >> > >> How can this be any use? It could change the instant after you read it. > > > > For statistical sampling, that doesn't matter. > > Fair enough, but wouldn't that be easier to do by creating an array (inside > the kernel), and logging which cpus it goes on and off at which time, rather > than polling for it? Migrates should be rare ... copying the currently > maintained sys/user time stuff at migrate would work, I'd think ... if you > really need the stats. This is certainly a valid approach, but I would imagine that getting this into the standard kernel would be even tougher and more intrusive than adding a single simple fast system call. > > > For library use, this value changes slowly enough, > > especially with a NUMA aware scheduler, that it > > is extremely useful. If the thread grabs a snapshot of the > > cpu number and uses it to select an object from a pool known > > to be close (in some NUMA distance metric sense) to > > that CPU, the chances are _extremely_ high that that > > object will be close to the thread when it accesses it. > > OK ... but why not just ask the kernel for the memory and let it sort it > out? we're atomic whilst in the kernel, and moreover, new allocations > should default to being local anyway. Because a completely different set of threads with completely different affinity and possibly even running in a different process may have created the pool of objects. > > M. > > PS. For mem alloc you'd want the node number, not the cpu number anyway, > which is significantly less likely to change. Now that you mention it, it would be very nice to have a fast call to get the node too, but this could be built using a fast get cpu call. Also, this isn't just about allocation. Rather, its about finding where we are so we know which things are closest (the majority of the time at least). Brian |