Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpucontroller

[Hubert Tonneau <hubert.tonneau@fullpliant.org>]

The problem you have here is more fondamental:
Linux is for the first time getting seriouly behond Unix semantic.
Historically, you had only small behond Unix semantic issues at the corners,
I mean /proc or /sys, but with proper ressources management, they get central
for the first time.
The reason is that Unix semantic just fall short as far as ressources
management is concerned.

Basically, when you request some ressources, let's start with memory and
disk space, there are two possible scenario:
. either you want what you request to be reliably allocated over time or
  the request to fail immediately,
. or you want to maximize the ability to satisfy the request immediately
  with potencial imperative instruction from the operating system to shrink
  usage at a later point (or even direct takeback with no forwarn from the
  operating system)
The current disk quotas apply the first rule,
the current OOM killer applies the second rule.
None is good in facts because only the application can decide what kind
of failure (immediate or futur) it wants.
There is a third kind of ressources management (CPU, IO and network bandwith)
where the solution is easier because a two stages queue does it.

So, my preposed general picture to introduce proper ressources management is:
everthing in the system is connected to a service ID (including inodes);
then the kernel can be instructed with rules dispatching ressources amoung
services ID (as an example, 30% cpu and 50% disk space for the database)
Now, we can implement two stage queues for the CPU, IO, etc on one side,
and proper ressources recovery on the other for memory or disk space.
The allocation rule beeing that if the ressource is requested with immediat
failure it will fail as soon as the ressource quota for the given service
ID is exhausted,
and if a given ressource is exhausted at overall system stage, then the
process which most over consumed thanks to allocating with potencial futur
failure instead of immediat one is warned then killed if it does not shrink
fast enough (or some files are deleted in case of disk storage with a potencial
demon beeing called first to give it a change to make smarter decision)

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