From: Paul M. <Pau...@us...> - 2001-10-12 05:57:03
|
Hello, Paul! Took a first pass through your proposal -- good stuff! Some very interesting approaches! Some comments: Under "Desired Properties / Vendor neutral base", I recommend adding Tru64, HP-UX, AIX, etc. May as well be all-inclusive. ;-) Under "Implementation Layers", near the end of the second paragraph: "a small scale forking" seems a bit dramatic. That said, it would be good if the NUMA and SMP code paths used the same C code. A question on items 1, 2, and 3 under "Implementation Layers". Item 1 seems to indicate that the current use of bitmasks within the kernel can continue unchanged, but hints at longer-term changes. Do you envision the kernel moving towards using CpuMemMaps and CpuMemSets, or do you expect these two concepts to be strictly confined to user space? Under "Error cases" in the header file, you say that if you really want to force an application to use CPUs and memory from disjoint nodes (which you might in diagnostics or performance-measurement code), then the CpuMemSet memory list must contain CMS_DEFAULT_CPU. But CMS_DEFAULT_CPU is casted to cms_lcpu_t. Shouldn't it be cast instead to cms_lmem_t? Or is CMS_DEFAULT_CPU instead supposed to go on the CpuMemSet's list of CPUs? If the latter, does this allow the disjoint-node operation for CPUs and memory? (So that all the permitted CPUs are on one set of nodes, but all the permitted memory is on another set of nodes, and the two sets of nodes are disjoint.) First-touch and stripe policies seem to be missing from the list. Some of the OSes have also had least-memory-utilization policies. A cpumemset has no meaning except in the context of a cpumemmap, right? A cpumemmap maps the CPU numbers, while a cpumemset simply restricts them, right? (Could make it work either way, but things like getcpu() and getnode() need to be in sync with the choice.) For example, suppose that the CPUs are numbered 100, 101, 102, 103, and 104. Suppose that the cpumemmap is {100,102,103}, and that the cpumemset is {0,2}. What is the physical CPU corresponding to logical CPUs 0, 1, and 2? HP's launch policies include policies for CPU allocation (round robin and the like). My guess is that this requires either additional bits in cms_policy or another field for CPU (as opposed to memory) policies. Non-root processes are prohibited from creating cpumemmaps. Shouldn't they be allowed to create them, as long as they are subsets of the cpumemmap that they are currently running with? If non-root processes are really prohibited from playing with cpumemmaps, what happens to their children? Is the child's cpumemmap generated from the cpumemset/cpumemmap pair that the parent specified with CMS_CHILD? Or does the child just get copies of the CMS_CHILD cpumemset/cpumemmap? (At this point, I am favoring letting non-root processes manipulate cpumemmaps, with the restriction that any that are installed must be pure restrictions of the current cpumemmap.) There is no way to create either a cpumemmap or a cpumemset without querying for it. The intended usage is to query for this process's set/map, then manipulate the resulting structure? Is the user supposed to directly manipulate the fields of the cpumemmap and cpumemset? A few typos, possibly due to WikiWeb issues: "cpu's" -> "CPUs", "mem's" -> "memories", "preasure points" -> "pressure points", "CpumemSet" -> "CpuMemSet", etc. Enough questions for now! More later... Once again, some good stuff here! Thanx, Paul |