Cc: Yinghai Lu <yhlu.kernel@...>, Andrew Morton <akpm@...>, Andi Kleen <ak@...>, <mingo@...>, Christoph Lameter <clameter@...>, <linux-mm@...>, <linux-kernel@...>, Eric Dumazet <dada1@...>
Throughout the NUMA code you need a way to distinguish between an invalid
mapping and an actual node id. NID_INVAL is used to say there are no
additional node ids available for this system, the pxm-to-node mapping
doesn't yet exist, etc.
You can't get away with using a magic positive integer with those
semantics because CONFIG_NODES_SHIFT determines MAX_NUMNODES. All
nodemasks will have that many bits in their struct. So 255 will always be
a valid node id for shifts of 8 or larger. It isn't feasible to say for
these types of systems (or ia64 where the default shift is 10) that 255 is
some magic node id that means its invalid.
NID_INVAL is the only way to signify an invalid node id and that has
always been done with -1. So objects that store node ids that have the
possibility of being invalid must be signed. The only time you can use
unsigned objects are when you are guaranteed to have valid node ids.
You're assuming that CONFIG_NODES_SHIFT will never been larger than that
and you still wouldn't be able to use your new numanode_t for anything
that could return NID_INVAL.
You're spinning the argument. Most of those arrays are not simply
returning node ids; most are returning structs or are arrays of unsigned
long type that return addresses. Those are unaffected by your change.
Others are initdata and is freed after boot anyway.
The handful of arrays thoughout the source that return node ids and are
not initdata would only save MAX_NUMNODES number of bytes with your
change for 8-bytes instead of 16-bytes. You're right, you might save a
KB of memory with the change. It's not worth it, especially since they
need to be signed anyway.
David
--
