Kirill,

Chandra is on vacation and Gerrit also may not be around so let me try to
answer some of the questions.

Gerrit/Matt, feel free to correct.

Kirill Korotaev wrote:
> Gerrit, Chandra,
> 
> we have a number of questions regarding CKRM code - first of all, what
> is the right place to ask them?

This mailing list is the right place.


> we looked through the code available at SF and basically while there is
> a job to be done it does look like both CKRM and OpenVZ-UBC projects
> (http://openvz.org) can benefit from each other and it is possible to
> make both projects mergeable. 

Yes, there's no doubt that OpenVZ and CKRM can be mutually beneficial. The 
early version
of CKRM was used by the PlanetLab folks (Marc Fiucynzski) in conjunction with 
vservers to
provide a hosting environment for multiple users with CKRM providing the QoS.


>Our questions mainly concerns what
> populates the framework itself:
> 1. what is the base kernel version used for CKRM? And what version is
> recommended to use/investigate/study?

All future work is going to be in the context of the "f-series" of ckrm
which is currently posted agains 2.6.14. As newer f-series come out, they'll
use the latest stable kernel version possible so there's no one version which
will be fixed as base for a long time, just like regular kernel development.

So, for now, the answer is 2.6.14.

> On the site I can see that most part of the code is available in krm-old
> branch only. Is it for 2.6.8 kernel?

The e17 version of ckrm (which is the most recent component of the ckrm-old 
section) is against 2.6.10.
But please don't use that. Any new work should start with the f series.

> 2. CPU scheduler
> 
> - Do you have any benchmarks of CKRM CPU scheduler?
> For example, Java Volano benchmark? What is the overhead of CKRM CPU
> scheduler on SMP system compared to native Linux CPU scheduler?
> 
> - Is CKRM CPU scheduler SMP-scalable? Do you have any benchmark results
> available?

The overhead of the old CKRM CPU scheduler using lmbench has been shown in the 
OLS 2004 presentation slides
http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf

and it was shown to be low and scaling with number of CPUs.
But that no longer matters for future development since the new direction being
taken for the CPU scheduler is based on subcpusets which is being discussed on 
the list
and for which Maeda-san can give more details.
        


> 3. Why have you started implementing your own I/O scheduler? Is there
> something wrong with recent CFQ Linux I/O scheduler? With CFQv2?

A new I/O scheduler was used because
- CFQ group's I/O by pid (for sync I/O) whereas CKRM needs it to be done by 
"CKRM class"
(not to be confused with CFQ's class :-)
- CFQ only regulates I/O based on a relative criteria (the I/O priority of the 
submitting task), whereas CKRM needs
regulation to happen per-class based on *two* *absolute* criteria - guarantee 
and limit. The range of allowable values
for guarantee and limit are larger than those for I/O priorities and different 
semantics are associated with them.

So it was best to create a new I/O scheduler, atleast to begin with. However, 
the number of changes needed to the CFQ
code base to yield an I/O scheduler suitable for CKRM are quite small so there 
is a possibility of reusing CFQ's code (just as
there are dupes between CFQ and deadline iosched code) but thats not something 
thats a priority right now.

Incidentally, the CFQv2/v3-based I/O controller (which is I/O scheduler + all 
the stuff needed to work within the CKRM framework)
for f series isn't out yet. I'm only just starting to work on it.

> 
> 4. Memory accounting. Do you plan to improve handling of shared pages?
> Do you have any roadmap available? Right now the sum of memory
> consumption of classses can exceed physical memory available which is
> very confusing... Do you plan to account/limit any other kernel objects
> (slabs, page tables, etc.)?

Valerie can probably address this better since I've been out of sync with the 
mem controller for sometime now.

> and frankly there is a feeling that many code at SF is kind of obsolete.
> Can we get a "real" patch? i mean current one if it is available, or for
> any version kernel which you think is complete?

The "ckrm-development" branch under
http://sourceforge.net/project/showfiles.php?group_id=85838

is the right place to get the patches. It has the cpu and mem controllers and 
the ckrm framework.
And in the past 2-3 months atleast, snapshots of the current work have been 
uploaded regularly.

We don't have a cvs/git type tree....was that what you expected as "current" ?

-- Shailabh


> 
> Thank you,
> OpenVZ kernel leader,
> Kirill Korotaev
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech

Reply via email to