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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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