From: Paul J. <pj...@en...> - 2002-01-12 10:18:11
|
On Wed, 9 Jan 2002, Michael Hohnbaum wrote: > Paul, > > I appreciate that you have addressed most of my concerns in > your latest revision of CpuMemSets. At this point in time I > have little to add, although, as we have previously discussed, > there is a need for adding grouping capabilities to CpuMemSet. > Next week I'll try to post some thoughts on this. > > A question that has been brought up is how would one remove a > resource (CPU or memory block) from the system via CpuMemSets? > The only option I see now is to use the bulk remap capability > and map a different resource to replace the resource being > removed. So, for example, if on an eight processor system, > processor 5 was being removed, one would have to choose a > different processor, say 6, to map what had been mapped to 5. > Thus a processor list, assuming all system processors were > being mapped by a CpuMemMap one to one, would be bulk remapped > to look like {0,1,2,3,4,6,6,7}. Is my understanding correct? > If so, while technically possible, there are numerous problems > I see with this, especially with respect to implications on > cpumemsets based on the now changed cpumemmap. > > Michael Hohnbaum > hoh...@us... Your crystal ball is working at full strength. I'd advise you to visit Las Vegas and bet heavily. In other words, in the final round of changes before packaging up our first patch (should be out next week, crossing my fingers), the only significant design detail that took a hit was the usefulness of the Bulk Remap feature. It seems to me, by my present understanding, that we must insist that the CpuMemMap memory lists be injective - meaning that you can't list a cpu twice in the memory lists. Or if we allow duplicates (such as cpu '6' in your example above) then as you state "there are numerous problems". Any ideas? I agree that the "canonical" scenario to be solved with bulk remap, or some other design element, is removing a cpu from a system. I also look forward to your thoughts on "grouping". That should be a "fun" challenge. I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |