Here is the general picture:
. each process is assigned to a service (Ingo pointed out that service
could be group)
. each service has a profile specifying how many CPU percent, memory, threads
handle, etc is assigned to it
. each service is assigned a timeout for shrinking ressources usage
The key idea is that the service profile does not prevent any process within
a service to get more ressources that what's assigned to the service, but
in case of lack of ressources, the profile will be used to decide who must
release some ressources.
Let's assume that at a given point, the kernel lacks of handles. Then
for each service, it will compute total handles consumed minus assigned
in the service profile. For the service having the highest difference,
it will send a signal to all processes in the service specifying 'hey,
you must close some handles'. Now, if after the service shrinking timeout
has ellapsed, there is still no handle available, the kernel will start
killing the processes within the faulty service.
The special case of CPU: As I suggested to Ingo, this would mean switching
the scheduler from a flat model (one process is selected to run) to a two
levels model (one service is selected to run, then one process within the
selected service is selected to run)
With such a service notion, you can have several services running in
one powerfull computer, let's say one SQL server, file sharing, and many
HTTP servers running chrooted, and be granted that if one web site
is suddenly under high load, then it will be abble to get most of the
ressources, including most of the CPU time, but will not be abble to disturb
other services, since they will still receive their assigned percentage of
the CPU when they require it, and in case of complete ressources stavation,
the right process (the one which is the most outside of it's profile)
will be killed first.
My view of the problem is that historically in Unix, one service was
basically one process. This is no more true and that's why the service
(once again, Ingo said it could be group) notion has to be introduced.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:20 EST