Re: [ckrm-tech] Re: [RFC] Revised CKRM release

From: Hubertus Franke
Date: Sat May 01 2004 - 08:13:23 EST


Rik van Riel wrote:

On Fri, 30 Apr 2004, Shailabh Nagar wrote:


Rik van Riel wrote:





User Mode Linux could definitely be an option for implementing
resource management, provided that the overhead can be kept
low enough.


....and provided the groups of processes that are sought to be regulated as a unit are relatively static.



Good point, I hadn't thought of that one.

It works for most of the workloads I had in mind, but
you're right that it's not good enough for eg. the
university shell server.



Let's keep in mind that UML provides you a virtual machine, its an architecture.

"User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. " straight from the side.

It has its well deserved place, its great for fault protection isolation, but it does have performance hits.
Futhermore, there is no resource management associated with it. As we pointed out at last year's OLS. UML and CKRM would go great in concert, as CKRM could deliver the resource management underneath.
AFAIK, UML tasks manifest themselves as tasks in the host, hence the UML image would provide naturally a class that could be assigned resources under CKRM.

One part that can not be done with virtual machines is the case of a shared middleware, where different classes of work are driving through a shared space.

UML and CKRM solve different issues and IMHO they nicely complement each other.

For these purposes, "low enough" could be as much as 30%
overhead, since that would still allow people to grow the
utilisation of their server from a typical 10-20% to as
much as 40-50%.


In overhead, I presume you're including the overhead of running as many uml instances as expected number of classes. Not just the slowdown of applications because they're running under a uml instance (instead of running native) ?

I think UML is justified more from a fault-containment point of view (where overheads are a lower priority) than from a performance isolation viewpoint.

In any case, a 30% overhead would send a large batch of higher-end server admins running to get a stick to beat you with :-)



True enough, but from my pov the flip side is that
merging the CKRM memory resource enforcement module
has the potential of undoing lots of the performance
tuning that was done to the VM in 2.6.

That could result in bad performance even for the
people who aren't using workload management at all...



I am sure that can be worked out .. take a look at the history of NUMA support
When initially NUMA support was put in it was done through hooks at various interfaces.
Now its nicely embedded and abstracted out through macros in the memory space
and similar stuff is happening in the scheduler area through the introduction of sched domains.
We don't pay for NUMA or SMT if we are running on a single CPU system.

So I/we presume a similar progression will take place here. CKRM in its current
state provides you the infrastructure in the kernel. The way it is written or intended,
it should provide no overhead when not configured, neglible overhead when compiled
in but not used and "minimal/acceptable" overhead when resource management is enabled.

-- Hubertus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/