Ken wrote:
> If this is odd, do you have any suggestions for alternative?
No, I don't. Sorry.
It's a touchy problem, and I'm not enough of an expert to know what the
right tradeoffs are in this matter.
I agree with your point that if you realize what's going on, namely
that what cpuset the task reading meminfo is in affects the HugePages
values that are read, then one can use the interface easily enough.
... how about:
1) don't change the existing HugePages_* values - keep them
system-wide, and
2) adding two new values, by such names as:
Current_Cpuset_HugePages_Total: 0
Current_Cpuset_HugePages_Free: 0
That's certainly an uglier proposal than yours ;). But at least it
seems clearer, and doesn't make incompatible changes to what's there.
It does require user level code change to actually benefit from the
new values, whereas your patch sort of sneaks them in, on the assumption
that the majority of reads of these values would really prefer getting
the cpuset relative totals instead.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
