Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 May 2002 11:51:00 +0200
From:      Andy Sporner <sporner@nentec.de>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-hackers <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: Can I get some comment on my RFC???
Message-ID:  <3CF20184.8000302@nentec.de>
References:  <3CEDFEEB.30305@nentec.de> <3CEEA7C4.B08415DD@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:

>Andy Sporner wrote:
>
>>Hi Hackers,
>>
>>I would really like to have some input otherwise I might consider how
>>usefull my
>>participation on this list really is...
>>
>
>Well, far be it for me not to comment, particularly if the lack of
>comments could hinder your future participation...
>
I had the impression, thought it is rapidly diminishing that only certain
people make impacts.  I guess it is all about how to ask the question ;-)

>
>To me, this looks like a partial implementation of resource
>containers, with the ability to put each process into an
>arbitrary resource group
>
>
>If your need is to track all processes owned by "init", which is
>what you say, then really, you are trying to solve a much
>smaller problem than the patches you give solve.
>

It's possible I incorrectly stated the problem.    I needed a container
system to track an application (which might include daemon processes
that normally attach themselves to init as a parent, or change their
Group id) in a way they could not shake off the tagging.  The idea
was in the cluster software to guage how much resources (by walking
the process table and adding up the resources (CPU for example)).   This
was to be used to find the best node to (re)start an application on failure
of a node or on the initial start of the application.   My initial approach
was very static (no such patch) and it worked, but not well enough.    For
the sake of brevity, I wanted use the actual usage against the configured
limit (a soft limit) to make decision on where to (re)start an application.

I spent about 3 hours one afternoon in one of my better hacking
moods putting this together.

>
>However, I think your patches are really very useful.
>
Coming from you, I take high regard from this, thanks!

>
>Obviously, you could do this by GID, instead, if your different
>classes of "demanding users" ran under different default GIDs;
>and since an applicaiton could run under a GID via a single
>system call, and since it's required to make a system call to
>run under a different "application ID"...
>
>I'm not really positive that you've done anything that's really
>orthogonal to the default GID, in terms of providing additional
>information -- with the exception of the inheritance.
>
That's the point, inheritance (and as I said I want this to be the stuff
the process can not shake off it's feet--without knowledge of how).

>
>I would suggest that you restrict access to the cse_set_id(2)
>call.  I would also suggest that you change it's name, and make
>it a mux system call: it's likely that people are going to find
>all sorts of things they want to do with the value of this; an
>obvious one will be "getcseid", and another obvious one will be
>"getpcseid" (this latter is lacking for groups; thus your ID
>bears the same relationship to GID as UID bears to GID; i.e. it's
>an orthogonal credential value).
>
I agree, I will do this.  I also agree this this should be make as universal
as possible.  


The only sticking point *might* be the other members of
the structure that will be later used for process migration (as in Mosix).
I have a working approach to failing over network sockets, though
lacking in implementation.  With this hardware device I am making that
can switch the sheer number of trafic, I will use it as a front-end to a
cluster and as part of the "migration" the registration of the endpoint
will be changed on the "front-end".

On another point of usage, it could be a good way of tracking affinity
of resources (as with process migration) so you don't have cross-node
page fault wars (IE: Shared memory), so that if you move one process,
you would have to move all in the group.  I would like to start a dialog
on this, but yes, I know the cluster list would be the right place ;-)

BTW:  CSE stands for (Clustered System Environment)  so a name
change would be very much needed to support a generic case.  Perhaps
the best thing is to split the patch into two and place the other members
in another structure (since it is likely to grow) and perhaps if this patch
is usefull it would be good to have it without having to have the clustering
stuff too.  

 > *** Many other good points ***

Thanks for your import--that was the goal of my 'RFC'.  Now I have
enough to go back and do some more work on it.  I will post the new
changes to my website later this week along with another piece of
candy (graphical top), which was another piece salvaged from my
clustering stuff.  It's not clear if I will continue this clustering project
for many reasons (mostly time related), days seem like months when
I say I will put things out and I am sure there are those that think it
doesn't exist at all.  So this way I can do things more incrementally
if at all.

Best Regards



-Andy





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF20184.8000302>