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: <20061107123458.e369f62a.pj@sgi.com>
Date:	Tue, 7 Nov 2006 12:34:58 -0800
From:	Paul Jackson <pj@....com>
To:	"Paul Menage" <menage@...gle.com>
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,
	matthltc@...ibm.com, dipankar@...ibm.com, rohitseth@...gle.com
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

Paul M wroteL
> One of the issues that crops up with it is what do you put in
> /proc/<pid>/container if there are multiple hierarchies?

Thanks for your rapid responses - good.

How about /proc/<pid>/containers being a directory, with each
controller having one regular file entry (so long as we haven't done
the multiple controller instances in my item (5)) containing the path,
relative to some container file system mount point (which container
mount is up to user space code to track) of the container that contains
that task?

Or how about each controller type, such as cpusets, having its own
/proc/<pid>/<controller-type> file, with no generic file
/proc</pid>/container at all.  Just extend the current model
seen in /proc/<pid>/cpuset ?

Actually, I rather like that last alternative - forcing the word
'container' into these /proc/<pid>/??? pathnames strikes me as
an exercise in branding, not in technical necessity.  But that
could just mean I am still missing a big fat clue somewhere ...

Feel free to keep hitting me with clue sticks, as need be.

It will take a while (as in a year or two) for me and others to train
all the user level code that 'knows' that cpusets are always mounted at
"/dev/cpuset" to find the mount point for the container handling
cpusets anywhere else.

I knew when I hardcoded the "/dev/cpuset" path in various places
in user space that I might need to revisit that, but my crystal
ball wasn't good enough to predict what form this generalization
would take.  So I followed one of my favorite maxims - if you can't
get it right, at least keep it stupid, simple, so that whomever does
have to fix it up has the least amount of legacy mechanism to rip out.

However this fits in nicely with my expectation that we will have
only limited need, if any, in the short term, to run systems with
both cpusets and resource groups at the same time.  Systems just
needing cpusets can jolly well continue to mount at /dev/cpuset,
in perpetuity.  Systems needing other or fancier combinations of
controllers will need to handle alternative mount points, and keep
track somehow in user space of what's mounted where.

And while we're here, how about each controller naming itself with a
well known string compiled into its kernel code, and a file such
as /proc/containers listing what controllers are known to it?  Not
surprisingly, I claim the word "cpuset" to name the cpuset controller ;)

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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/