Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > if CKRM is just extensions, I think it should be an external patch. > > if it provides a path towards unifying the many disparate RM mechanisms > > already in the kernel, great! > > OK, so if it provides a path towards unifying these, what should happen > to the old interfaces when they conflict with those offered by CKRM? I don't think the name matters, as long as the RM code is simplified/unified. that is, the only difference at first would be a change in name - same behavior. > For instance, I'm considering how a per-class (re)nice setting would > work. What should happen when the user (re)nices a process to a > different value than the nice of the process' class? Should CKRM: it has to behave as it does now, unless the admin has imposed some class structure other than the normal POSIX one (ie, nice pertains only to a process and is inherited by future children.) > a) disable the old interface by > i) removing it > ii) return an error when CKRM is active > iii) return an error when CKRM has specified a nice value for the > process via membership in a class > iv) return an error when the (re)nice value is inconsistent with the > nice value assigned to the class some interfaces must remain (renice), and if their behavior is implemented via CKRM, it must, by default, act as before. other interfaces (say overcommit_ratio) probably don't need to remain. > b) trust the user, ignore the class nice value, and allow the new nice > value users can only nice up, and that policy needs to remain, obviously. you appear to be asking what happens when the scope of the old mechanism conflicts with the scope determined by admin-set CKRM classes. I'd say that nicing a single process should change the nice of the whole class that the process is in, if any. otherwise, it acts to rip that process out of the class, which is probably even less 'least surprise'. > This sort of question would probably come up for any other CKRM > "embraced-and-extended" tunables. Should they use the answer to this > one, or would it go on a case-by-case basis? I don't see that CKRM should play by rules different from other kernel improvements - preserve standard/former behavior when that behavior is documented (certainly nice is). in the absense of admin-set classes, nice would behave the same. all CKRM is doing here is providing a broader framework to hang the tunables on. it should be able to express all existing tunables in scope. - 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/
Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote: > > > actually, let me also say that CKRM is on a continuum that includes > > > current (global) /proc tuning for various subsystems, ulimits, and > > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > > > being useful and fast enough to subsume the current global and per-proc > > > tunables. after all, there are MANY places where the kernel tries to > > > maintain some sort of context to allow it to tune/throttle/readahead > > > based on some process-linked context. "embracing and extending" > > > those could make CKRM attractive to people outside the mainframe market. > > > > Seems like an excellent suggestion to me! Yeah, it may be possible to > > maintain the context the kernel keeps on a per-class basis instead of > > globally or per-process. > > right, but are the CKRM people ready to take this on? for instance, > I just grepped 'throttle' in kernel/mm and found a per-task RM in > page-writeback.c. it even has a vaguely class-oriented logic, since > it exempts RT tasks. if CKRM can become a way to make this stuff > cleaner and more effective (again, for normal tasks), then great. > but bolting on a big new different, intrusive mechanism that slows > down all normal jobs by 3% just so someone can run 10K mostly-idle > guests on a giant Power box, well, that's gross. > > > The real question is what constitutes a useful > > "extension" :). > > if CKRM is just extensions, I think it should be an external patch. > if it provides a path towards unifying the many disparate RM mechanisms > already in the kernel, great! OK, so if it provides a path towards unifying these, what should happen to the old interfaces when they conflict with those offered by CKRM? For instance, I'm considering how a per-class (re)nice setting would work. What should happen when the user (re)nices a process to a different value than the nice of the process' class? Should CKRM: a) disable the old interface by i) removing it ii) return an error when CKRM is active iii) return an error when CKRM has specified a nice value for the process via membership in a class iv) return an error when the (re)nice value is inconsistent with the nice value assigned to the class b) trust the user, ignore the class nice value, and allow the new nice value I'd be tempted to do a.iv but it would require some modifications to a system call. b probably wouldn't require any modifications to non-CKRM files/dirs. This sort of question would probably come up for any other CKRM "embraced-and-extended" tunables. Should they use the answer to this one, or would it go on a case-by-case basis? Thanks, -Matt Helsley - 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/
Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > actually, let me also say that CKRM is on a continuum that includes > > current (global) /proc tuning for various subsystems, ulimits, and > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > > being useful and fast enough to subsume the current global and per-proc > > tunables. after all, there are MANY places where the kernel tries to > > maintain some sort of context to allow it to tune/throttle/readahead > > based on some process-linked context. "embracing and extending" > > those could make CKRM attractive to people outside the mainframe market. > > Seems like an excellent suggestion to me! Yeah, it may be possible to > maintain the context the kernel keeps on a per-class basis instead of > globally or per-process. right, but are the CKRM people ready to take this on? for instance, I just grepped 'throttle' in kernel/mm and found a per-task RM in page-writeback.c. it even has a vaguely class-oriented logic, since it exempts RT tasks. if CKRM can become a way to make this stuff cleaner and more effective (again, for normal tasks), then great. but bolting on a big new different, intrusive mechanism that slows down all normal jobs by 3% just so someone can run 10K mostly-idle guests on a giant Power box, well, that's gross. > The real question is what constitutes a useful > "extension" :). if CKRM is just extensions, I think it should be an external patch. if it provides a path towards unifying the many disparate RM mechanisms already in the kernel, great! > I was thinking that per-class nice values might be a good place to > start as well. One advantage of per-class as opposed to per-process nice > is the class is less transient than the process since its lifetime is > determined solely by the system administrator. but the Linux RM needs to subsume traditional Unix process groups, and inherited nice/schd class, and even CAP_ stuff. I think CKRM could start to do this, since classes are very general. but merely adding a new, incompatible feature is just Not A Good Idea. regards, mark hahn. - 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/
Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote: > actually, let me also say that CKRM is on a continuum that includes > current (global) /proc tuning for various subsystems, ulimits, and > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up > being useful and fast enough to subsume the current global and per-proc > tunables. after all, there are MANY places where the kernel tries to > maintain some sort of context to allow it to tune/throttle/readahead > based on some process-linked context. "embracing and extending" > those could make CKRM attractive to people outside the mainframe market. Seems like an excellent suggestion to me! Yeah, it may be possible to maintain the context the kernel keeps on a per-class basis instead of globally or per-process. The real question is what constitutes a useful "extension" :). I was thinking that per-class nice values might be a good place to start as well. One advantage of per-class as opposed to per-process nice is the class is less transient than the process since its lifetime is determined solely by the system administrator. CKRM calls this kind of module a "resource controller". There's a small HOWTO on writing resource controllers here: http://ckrm.sourceforge.net/ckrm-controller-howto.txt If anyone wants to investigate writing such a controller please feel free to ask questions or send HOWTO feedback on the CKRM-Tech mailing list at . Thanks, -Matt Helsley - 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/
