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

Shailabh Nagar
2004-04-30T20:15:45Z

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

Agreed - CKRM's memory controller logic needs major rework for it to
be acceptable....but I'm sure you can do something about it, Rik ! :-)

The cpu and I/O controllers will also have to be reworked since we now
have the hierarchical class requirement as well as lower and upper
bounds for shares.

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

Even with the earlier logic, the hope was that if people are not using
workload management at all, then the only overhead they would see
would be the extra indirection into "find next class to schedule" (in
any controller) since there would be only one default class in the
system. In the cpu case, this overhead had been shown to be as low as
1-2% but memory overhead had not been measured.

Keeping overheads low (or zero) for those who don't care to use CKRM
functionality is a high-priority design goal. Keeping it proportional
to number of classes (with more significant degradations seen if the
number of hierarchy levels increase) comes next.

Also, will the 2.6 VM improvements continue to work as designed if
multiple UML instances are running, each replicating a large memory
user (like say a JVM or a database server) ? Taking the application
server serving a number of different customers. If we have to
replicate the app server for each customer class (one on each UML
instance), the app server's memory needs would get added to the
equation n times and the benefits of 2.6 VM tuning might be lost.

-- Shailabh