Erich Focht <[EMAIL PROTECTED]> wrote: > > May I translate the first sentence to: the requirements and usage > models described by Paul (SGI), Simon (Bull) and myself (NEC) are > "fairly obscure" and the group of users addressed (those mainly > running high performance computing (AKA HPC) applications) is "very > limited"? If this is what you want to say then it's you whose view is > very limited.
Martin makes a legitimate point. We're talking here about a few tens or hundreds of machines world-wide, yes? And those machines are very high-value so it is a relatively small cost for their kernel providers to add such a highly specialised patch as cpusets. These are strong arguments for leaving cpusets as an out-of-kernel.org patch, for those who need it. On the other hand, the impact is small: 25-akpm/fs/proc/base.c | 19 25-akpm/include/linux/cpuset.h | 63 + 25-akpm/include/linux/sched.h | 7 25-akpm/init/Kconfig | 10 25-akpm/init/main.c | 5 25-akpm/kernel/Makefile | 1 25-akpm/kernel/cpuset.c | 1550 ++++++++++++++++++++++++++++++++++++++ 25-akpm/kernel/exit.c | 2 25-akpm/kernel/fork.c | 3 25-akpm/kernel/sched.c | 8 25-akpm/mm/mempolicy.c | 13 25-akpm/mm/page_alloc.c | 13 25-akpm/mm/vmscan.c | 19 So it's a quite cheap patch for the kernel.org people to carry. So I'm (just) OK with it from that point of view. My main concern is that the CKRM framework ought to be able to accommodate the cpuset function, dammit. I don't want to see us growing two orthogonal resource management systems partly because their respective backers have no incentive to make their code work together. I realise there are technical/architectural problems too, but I do fear that there's a risk of we-don't-have-a-business-case happening here too. I don't think there are any architectural concerns around cpusets - the major design question here is "is CKRM up to doing this and if not, why not?". From what Hubertus has been saying CKRM _is_ up to the task, but the cpuset team may decide that the amount of rework involved isn't worthwhile and they're better off carrying an offstream patch. But we're not there yet - we're still waiting for the design dust to settle. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
