From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Sun 21 Oct 2001 - 23:58:56 BST
On Sun, 21 Oct 2001 15:27:37 -0500, Rik van Riel wrote
> Hi,
>
> I'm looking at your vserver patch (2.4.10ctx-2) right
> now and I must say I'm impressed. The thing looks pretty
> functional already and minimal enough that I can actually
> use it without worrying ;)
Indeed this is the key of this project. Almost found by accident
> However, the system call numbers your patch uses (222 and 223)
> are already taken by TUX and LSM. I think it would be better
> to ask Linus for one or two system calls to be reserved for
> your project.
Yes I was aware of that. I started in 2.4.9 and then I saw the problem
in 2.4.10. I tought it was a little soon to reserve the syscall number as
this project is still young. Maybe it does not matter and Linus will grant
those entries.
> Other than that, I think I'll try it. If there are any major
> TODO items left, let me know and maybe I can implement some.
There are some issues we would like to cover. Some are already cover
I think.
The new_s_context syscall has been enhanced with a third argument. A flag
(bit set). One flag is used to lock the security context. This means the caller
is allocated a new security context and can't ask a new one.
The other flag impact the schedular. The priority of a process in a security
context is controlled by the activity of all processes in the same security
context. This produced some sort of fairness between the vservers.
The first flag (lock) takes its importance here.
I will release a patch probably tuesday with this feature. It is still trivial
Now to get somewhat more robust vservers, it would be nice if
we could limit globally the resources used by all processes in a given
vserver.
Currently, the new_s_context syscall introduce a struct context_info *
shared by all processes in a given security context. This context_info
contains the hostname and domainname, the new flag (lock and sched) and
may contain various resource counters (memory used, file handle and so on).
So we could have a "per security context" ulimit.
Note that this resource limit and schedular thing has broader usage
than vservers. For example, we could modify the new_s_context syscal;
to allocate a new context_info struct for a process, yet keeping the same
security ID. This could be used to implement stuff like per-user fair scheduling
and resource management. Well, per something, per context ...
What do you think ? I believe you have much experience on this side
of the kernel.
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc