linux-kernel - Re: [ckrm-tech] [RFC] Resource Management

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]

Message-ID: <45460E69.7070505@openvz.org>
Date:	Mon, 30 Oct 2006 17:38:33 +0300
From:	Pavel Emelianov <xemul@...nvz.org>
To:	Paul Jackson <pj@....com>
CC:	Pavel Emelianov <xemul@...nvz.org>, vatsa@...ibm.com,
	dev@...nvz.org, sekharan@...ibm.com, menage@...gle.com,
	ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
	haveblue@...ibm.com, linux-kernel@...r.kernel.org,
	matthltc@...ibm.com, dipankar@...ibm.com, rohitseth@...gle.com,
	devel@...nvz.org
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

Paul Jackson wrote:
> Pavel wrote:
>> 1. One of the major configfs ideas is that lifetime of
>>    the objects is completely driven by userspace.
>>    Resource controller shouldn't live as long as user
>>    want. It "may", but not "must"!
> 
> I had trouble understanding what you are saying here.
> 
> What does the phrase "live as long as user want" mean?

What if if user creates a controller (configfs directory)
and doesn't remove it at all. Should controller stay in memory
even if nobody uses it?

> 
> 
>> 2. Having configfs as the only interface doesn't alow
>>    people having resource controll facility w/o configfs.
>>    Resource controller must not depend on any "feature".
>>
>> 3. Configfs may be easily implemented later as an additional
>>    interface. I propose the following solution:
>>      - First we make an interface via any common kernel
>>        facility (syscall, ioctl, etc);
>>      - Later we may extend this with configfs. This will
>>        alow one to have configfs interface build as a module.
> 
> So you would add bloat to the kernel, with two interfaces
> to the same facility, because you don't want the resource
> controller to depend on configfs.
> 
> I am familiar with what is wrong with kernel bloat.
> 
> Can you explain to me what is wrong with having resource
> groups depend on configfs?  Is there something wrong with

Resource controller has nothing common with confgifs.
That's the same as if we make netfilter depend on procfs.

> configfs that would be a significant problem for some systems
> needing resource groups?

Why do we need to make some dependency if we can avoid it?

> It is better where possible, I would think, to reuse common
> infrastructure and minimize redundancy.  If there is something
> wrong with configfs that makes this a problem, perhaps we
> should fix that.

The same can be said about system calls interface, isn't it?
-
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/