Btw., the kernel tree that I am working with is available via anon cvs. To get the version of the specific kernel with CKRM enabled (as mentioned in my previous email), please use the planetlab_1_rc1 tag. E.g., the following recipe will cvs checkout, build and install precisely the kernel that I have:
cvs -d :pserver:[EMAIL PROTECTED]:/cvs co -r planetlab_1_rc1 linux-2.6 cd linux-2.6 cp configs/kernel-2.6.8-i686-planetlab.config .config make oldconfig make sudo make modules_install install As mentioned, I use this on a Fedora Core 2 system. Your milage will vary if you are using a distribution. Best, Marc > -----Original Message----- > From: Marc E. Fiuczynski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 28, 2004 1:25 PM > To: ckrm-Tech > Subject: performance and stability issues with CKRM > > > Hello, > > I have the latest CKRM patches for all controllers applied to my > tree. Specifically, I am using cpu v7, io v4, and mem v1 > controllers with e16rc1 which we released over the past few days > --- i.e., the most recent code that addresses most of the > outstanding issues. My kernel is configured with all things CKRM > related statically compiled into my kernel, but I did not select > the socket controller nor the LRU ordering options for the memory > controller. Note that my kernel is based off of Fedora Core 2 > 1.521 (linux 2.6.8.1), rather than just plain vanilla 2.6.8.1 > from kernel.org. > > As I actually enjoy eating my own dogfood, I run this kernel on > my Dell Inspiron 5150 laptop and then use it for kernel > compilations, email (running MS Outlook via cxoffice), etc.. > This way I get a good feel for its base performance -- > particularly interactivity -- and forces me to immediately > address stability issues. By base performance I am referring to > using a system that does not create any classes in > /rcfs/taskclass; everything is running in the base class. > > In terms of performance, my general sense is that the systems > with the CKRM controllers feels sluggish compared to running a > FC2 1.521. Compiles of the kernel appear to take a longer --- > I've reported on this before. Unfortunately, due to lack of > time, I don't have hard statistics to back this up. Moreover, I > don't have a good sense which CKRM controller is causing the sluggishness. > > In terms of stability, it appears the i/o controller causes the > system to hang while doing a kernel compile (make -j 3). Of > course, after several hard reboots the filesystem was corrupted. > Trying to fix the filesystem (ext) with the same kernel, fsk > would fail with a SIG_USR1 about 50% through the check. My > conjecture is that something is failing in the cfq-iosched.c code > that reflects this signal back to fsck. My reasonig for this is > that running the same fsck on a system booted with a vanilla FC2 > 1.521 kernel succeeded to clean the filesystem. Until the I/O > scheduler attains better stability, I plan to simply switch back > to the vanilla FC2 1.521 cfq-iosched.c. > > I'd like to hear about other experiences with CKRM so far. > > Best, > Marc > > > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
