?

Log in

Previous Entry | Next Entry

live from SCALE7x

Greetings from SCALE7x! Today will be the second (and the last) day of the show. Yesterday I did a presentation titled "Recent Advances in the Linux Kernel resource management". The scope of the talk is much more technical and narrow than my usual talk about containers. More to say, I was focusing more on mainstream Linux kernel (i.e. cgroups and memory controller) than on OpenVZ kernel (i.e. user beancounters).

I think the talk was well received and I had about 10 different interesting questions, one is puzzling enough so I was not able to provide a good answer. This is definitely a sign of a good audience.

If anyone is interested in slides from my presentation, they are available: OpenOffice ODP (276K), PDF (409K), PPT (437K).

Comments

( 5 comments — Leave a comment )
(Anonymous)
Mar. 13th, 2009 04:29 am (UTC)
Query on Scale7x ppt slide 8
"Problem: Most of IO is async"

Are u referring to Async IO syscalls or the arrival rate of IO being bursty here?
k001
Mar. 13th, 2009 06:26 am (UTC)
Re: Query on Scale7x ppt slide 8
No. I guess I'd better use the word "delayed" or something.

See, there is a process writing to a file. When a process calls write() the data is not actually being written, no I/O is happening. Instead a few pages in memory are created and marked with "we need to write that to disk". At some later point in time the actual write is happening.

The problem is by the time actual write to disk is happening we do not know on behalf of what process kernel does that (in fact, that process might already be finished). So it's not easy to account writes.

In OpenVZ the problem is solved with so-called I/O beancounters. Every page to be written is marked with a page beancounter which is attached to an I/O beancounter, and we do not loose these connections even if process exits. So when we do real write we do know who initiated it in the first place. This accounting makes sense per se, plus it is a prerequisite for correct group-based I/O scheduling.
(Anonymous)
Mar. 24th, 2009 04:57 pm (UTC)
Porting to mainstream
Your presentation says you're working on mainstreaming OpenVZ.

I've seen a pretty impressive stream of patches from OpenVZ developers, but it seems there is no git tree in place with 2.6.28+OpenVZ or 2.6.29+OpenVZ. I know that 2.6.29 has been released only hours ago, but it would be nice if you could give a statement about OpenVZ plans for 2.6.29 or 2.6.30 (specifically, whether any of these kernels will be the basis of a stable OpenVZ patch in the future).

Thanks for sharing that presentation and keep up the good work!
k001
Mar. 24th, 2009 05:51 pm (UTC)
Re: Porting to mainstream
Just to make sure everyone understands this: merging OpenVZ to mainstream is a task which is quite different from porting OpenVZ patchset to new mainstream kernels. These two tasks are almost orthogonal, one can spend his time either doing this or that.

Now, we have settled on 2.6.27 for quite a while because it's stated to be a long maintained kernel; updates for this kernel are still coming (and I hope will come for some time). That makes it a good platform for OpenVZ. Our current goal is to eventually stop maintaining 2.6.24 and 2.6.26 kernels and only leave 2.6.18-rhel5 (stable) and 2.6.27 (devel).

Currently we have no plans for 2.6.28 and 2.6.29, but this might change :)
(Anonymous)
Mar. 26th, 2009 11:40 am (UTC)
Re: Porting to mainstream
Hi Kir,

thanks for the explanation.

Having 2.6.27 as a base for OpenVZ is absolutely fine with me, considering that 2.6.27 is the basis for openSUSE 11.1 and SLES 11.

Merging OpenVZ functionality to mainstream is indeed preferable to porting the patchset.
( 5 comments — Leave a comment )

Latest Month

July 2016
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow