Oh good. I'd sort of guessed that part, but wasn't quite sure. (I've seen
hardware people do some amazingly odd things before. Luckily not recently,
So would a workable (if naieve) attempt to use Andrea's
memory-zones-grouped-into-classes approach on NUMA just involve making a
class/zone list for each node? (Okay, you've got to identify nodes, and
group together processors, bridges, DMAable devices, etc, but it seems like
that has to be done anyway, class/zone or not.) How does what people want to
do for NUMA improve on that?
Is a major goal of NUMA figuring out how to borrow resources from adjacent
nodes (and less-adjacent nodes) in a "second choice, third choice, twelfth
choice" kind of way? Or is a "this resource set is local to this node, and
allocating beyond this group is some variant of swapping behavior" approach
an acceptable first approximation?
If class/zone is so evil for NUMA, what's the alternative that's being
considered? (Pointer to paper?)
I'm wondering how the class/zone approach is more evil than the alternative
of having lots and lots of little zones which have different properties for
each processor and DMAable device on the system, and then trying to figure
out what to do from there at allocation time or during each attempt to
inflict I/O upon buffers.
P.S. Rik pointed out in email (replying to my "master of stupid questions"
signoff) that I am indeed confused about a great many things, but didn't
elaborate. Of course I agree with this, but I do try to make it up on volume
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/