lkml.org 
[lkml]   [2004]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ckrm-tech] Re: [RFC] Revised CKRM release
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:7.553 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site