On 5/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Adding Christoph Lameter <[EMAIL PROTECTED]> to the cc list, as he knows more about hugetlb pages than I do.This patch strikes me as a bit odd. Granted, it's solving what could be a touchy problem with a fairly simple solution, which is usually a Good Thing(tm). However, the idea that different tasks would see different values for the following fields in /proc/meminfo: HugePages_Total: 0 HugePages_Free: 0 strikes me as odd, and risky. I would have thought that usually, all tasks in the system should see the same values in the files in /proc (as opposed to the files in particular task subdirectories /proc/<pid>.) This patch strikes me as a bit of a hack, good for compatibility, but hiding a booby trap that will bite some user code in the long run. But I'm not enough of an expert to know what the right tradeoffs are in this matter.
Would annotating the Hugepages_* field with name of cpuset help? I orginally thought that since cpuset's mems are hirearchical in memory assignment, it is fairly straightforward to understand what's going on: parent cpuset stats include its and all of its children. For example, if root cpuset has two sub job1 and job2 cpusets, each has 20 and 30 htlb pages, when query at each level, we have: [EMAIL PROTECTED] echo $$ > /dev/cpuset/tasks [EMAIL PROTECTED] grep HugePages_Total /proc/meminfo HugePages_Total: 50 [EMAIL PROTECTED] echo $$ > /dev/cpuset/job1/tasks [EMAIL PROTECTED] grep HugePages_Total /proc/meminfo HugePages_Total: 20 [EMAIL PROTECTED] echo $$ > /dev/cpuset/job2/tasks [EMAIL PROTECTED] grep HugePages_Total /proc/meminfo HugePages_Total: 30 If this is odd, do you have any suggestions for alternative? - Ken - 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/
