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: <1162397041.12419.124.camel@localhost.localdomain>
Date:	Wed, 01 Nov 2006 08:04:01 -0800
From:	Matt Helsley <matthltc@...ibm.com>
To:	Pavel Emelianov <xemul@...nvz.org>
Cc:	vatsa@...ibm.com, dev@...nvz.org, sekharan@...ibm.com,
	ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
	haveblue@...ibm.com, linux-kernel@...r.kernel.org, pj@....com,
	dipankar@...ibm.com, rohitseth@...gle.com, menage@...gle.com,
	devel@...nvz.org
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

On Wed, 2006-11-01 at 11:01 +0300, Pavel Emelianov wrote:
> [snip]
> 
> >> 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".

	That's not true. It's possible for a resource control system that uses
a filesystem interface to operate without it's filesystem interface. In
fact, for performance reasons I think it's necessary.

	Even assuming your point is true, since you agree there should be only
one interface does it matter that choosing one prevents implementing
another?

	Why must a resource controller never depend on another "feature"?

> > One flexibility configfs (and any fs-based interface) offers is, as Matt
> > had pointed out sometime back, the ability to delage management of a
> > sub-tree to a particular user (without requiring root permission).
> > 
> > For ex:
> > 
> > 			/
> > 			|
> > 		 -----------------
> > 		|		  |
> > 	       vatsa (70%)	linux (20%)
> > 		|
> > 	 ----------------------------------
> > 	|	         | 	          |
> >       browser (10%)   compile (50%)    editor (10%)
> > 
> > In this, group 'vatsa' has been alloted 70% share of cpu. Also user
> > 'vatsa' has been given permissions to manage this share as he wants. If
> > the cpu controller supports hierarchy, user 'vatsa' can create further
> > sub-groups (browser, compile ..etc) -without- requiring root access.
> 
> I can do the same using bcctl tool and sudo :)

bcctl and, to a lesser extent, sudo are more esoteric.

Open, read, write, mkdir, unlink, etc. are all system calls so it seems
we all agree that system calls are the way to go. ;) Now if only we
could all agree on which system calls...

> > Also it is convenient to manipulate resource hierarchy/parameters thr a
> > shell-script if it is fs-based.
> > 
> >> 3. Configfs may be easily implemented later as an additional
> >>    interface. I propose the following solution:
> > 
> > Ideally we should have one interface - either syscall or configfs - and
> > not both.

To incorporate all feedback perhaps we should replace "configfs" with
"filesystem".

Cheers,
	-Matt Helsley

-
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/