lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 4 Aug 2006 15:35:17 +0100 From: Christoph Hellwig <hch@...radead.org> To: Kirill Korotaev <dev@...ru> Cc: Andrew Morton <akpm@...l.org>, vatsa@...ibm.com, mingo@...e.hu, nickpiggin@...oo.com.au, sam@...ain.net, linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de, balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com, haveblue@...ibm.com, pj@....com Subject: Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller On Fri, Aug 04, 2006 at 06:20:04PM +0400, Kirill Korotaev wrote: > For example: > 1. Should task-group be changeable after set/inherited once? > Are you planning to recalculate resources on group change? > e.g. shared memory or used kernel memory is hard to recalculate. I think this is a nice feature, although not on the top priority list. > 2. should task-group resource container manage all the resources as a whole? > e.g. in OpenVZ tasks can belong to different CPU and UBC containers. > It is more flexible and e.g. we used to put some vital kernel threads > to a separate CPU group to decrease delays in service. We already support different resource groups for the very limit rlimit interface. If we can keep the interface clean doing separate resource groups is fine. > 3. I also don't understand why normal binary interface like system call is > not used. > We have set_uid, sys_setrlimit and it works pretty good, does it? Yes. If you can design a syscall interface that is as clean as the two mentioned above a syscall interface is the best way to go forward. > 4. do we want hierarchical grouping? Not at all. It just causes a lot of pain an complexity for no real world benefits. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists