The following ten patches add the core of CKRM (Class Based Resource
Management) to Linux. Current patches are against 2.6.10-rc2. This
set of patches is essentailly a cleaned up version of what is
known on the [email protected] as the E16 code base.
As compared to E16, the patch breakout has been reorganized for easier
application to mainline with a number of stylistic cleanups more
in line with mainline kernel code.
The following patches include:
01-diff_ckrm_events:
Base CKRM events, mods to existing kernel code
02-diff_delay_acct:
More accurate accounting for CPU scheduling, IO scheduling
03-diff_ckrm_core:
Main/core CKRM code, beginings of Resource Control Filesystem
04-diff_rcfs:
Full directory suppport for rcfs
05-diff_taskclass:
Task based management for CPU, memory and Disk I/O.
06-diff_sockclass:
CKRM tracking for socket classes for inbound connection control,
bandwidth control, etc.
07-diff_numtasks:
Resource controller for number of tasks per class.
08-diff_listenaq:
Resource Controller for prioritizing inbound connection
requests. Can control queue weights for multiple accept
queues.
09-diff_rbce
A very basic rules based classification engine for automatically
adding tasks to classes. Also includes an enhanced rules based
classification engine with better per-process delay data and
ability to better monitor class related activities.
10-diff_docs
CKRM documentation.
Please send comments to [email protected]
thanks,
gerrit
Gerrit Huizenga <[email protected]> wrote:
>
> The following ten patches add the core of CKRM (Class Based Resource
> Management) to Linux.
How useful is this code at present? What are its limitations? And what is
the plan for future enhancements?
Thanks.
On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> The following ten patches add the core of CKRM (Class Based Resource
> Management) to Linux. Current patches are against 2.6.10-rc2. This
> set of patches is essentailly a cleaned up version of what is
> known on the [email protected] as the E16 code base.
> As compared to E16, the patch breakout has been reorganized for easier
> application to mainline with a number of stylistic cleanups more
> in line with mainline kernel code.
And where's the people who wrote the code? Are people at IBM really
all anxious cowards these days that can't submit their own code but have
to abuse a highlevel manager for it.
I must also say that I'm a bit disappointed by you, Gerrit. Either you
haven't actually read the code or I vastly overrated your taste.
On Mon, 29 Nov 2004 12:23:58 PST, Andrew Morton wrote:
> Gerrit Huizenga <[email protected]> wrote:
> >
> > The following ten patches add the core of CKRM (Class Based Resource
> > Management) to Linux.
>
> How useful is this code at present? What are its limitations? And what is
> the plan for future enhancements?
This set of code alone allows for creation of classes which include
per-class resource accounting (including delay accounting), basic
task management for memory, CPU and disk IO, limited socket & listener
queue management for networking, and the related rules based infrastructure.
So, in short, it is a useful set of code to work with to demonstrate
real utility with CKRM. However, this submission is not as full featured
as is being used by those on the ckrm-tech list, such as the PlanetLab
work. There are also things in SLES9 that are more featureful than
this set although those will be worked into here in time.
It does not have the full memory management and scheduler support that
other versions do and I'm not yet convinced that those are ready to
submit. Future enhancements will start with the cleanups as recommended
by lkml so far (thanks all ;-) followed by more work on the scheduler
and memory management side in the short term. There are also ways
to hook in additional resource controllers for any exhaustible resource,
e.g. file handles. setrlimit style resources, etc.
Most of the next level of changes will build on these and are based
on work currently in progress on the ckrm-tech list. However, this is
a stripped down set of code which is believed to be stable (tested on
IA32, x86-64, PPC64) with a variety of config options using both
standard regression suites (e.g. LTP, kernbench, the ckrm tests, etc.).
gerrit
On Mon, 29 Nov 2004 22:32:51 GMT, Christoph Hellwig wrote:
> On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> > The following ten patches add the core of CKRM (Class Based Resource
> > Management) to Linux. Current patches are against 2.6.10-rc2. This
> > set of patches is essentailly a cleaned up version of what is
> > known on the [email protected] as the E16 code base.
> > As compared to E16, the patch breakout has been reorganized for easier
> > application to mainline with a number of stylistic cleanups more
> > in line with mainline kernel code.
>
> And where's the people who wrote the code? Are people at IBM really
> all anxious cowards these days that can't submit their own code but have
> to abuse a highlevel manager for it.
>
> I must also say that I'm a bit disappointed by you, Gerrit. Either you
> haven't actually read the code or I vastly overrated your taste.
LOL, Christoph, Christoph... No, folks at IBM working on CKRM aren't
cowards, you'll see most of them on ckrm-tech or working with distros
or end users of the code or writing new code. You've seen them at KS
and OLS. Many are soaked up into a couple of other deliverables at
the moment but they'll be back.
We've needed some help in stabilizing and aggregating the code and so
we are using my copious free cycles. And, no, silly Christoph, I'm no
manager and never have been.
Yes, I've read the code, yes I cleaned up a bunch of it. But rather
than me sitting on it forever cleaning, I figured I'd shake it out and
get more eyes providing feedback which is where LKML is very handy.
Lots of eyes making sure that it is useful and minimally invasive never
hurts. And stewing it around just ckrm-tech is great for functionality
but less great for converging and cleanup. Hence, time to get this
into the wider eye of the community, including yours.
If you see needed cleanups, send me patches. If they make sense, I'll
integrate. If not, I'll go back to that training class on how to
deal with Christoph on LKML. ;-)
gerrit
On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> 09-diff_rbce
> A very basic rules based classification engine for automatically
> adding tasks to classes. Also includes an enhanced rules based
> classification engine with better per-process delay data and
> ability to better monitor class related activities.
This one didn't look like it made it to lkml.
Oh, and I stopped reviewing the other patches in the series, as the same
comments pretty much applied to them :(
thanks,
greg k-h
On Mon, 29 Nov 2004 18:43:21 PST, Greg KH wrote:
> On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> > 09-diff_rbce
> > A very basic rules based classification engine for automatically
> > adding tasks to classes. Also includes an enhanced rules based
> > classification engine with better per-process delay data and
> > ability to better monitor class related activities.
>
> This one didn't look like it made it to lkml.
>
> Oh, and I stopped reviewing the other patches in the series, as the same
> comments pretty much applied to them :(
Yeah, I checked marc earlier and didn't see it there. I'm making
the suggested changes now, will resend the whole set when I apply
and test a bit.
gerrit
On Mon, Nov 29, 2004 at 06:48:19PM -0800, Gerrit Huizenga wrote:
>
> On Mon, 29 Nov 2004 18:43:21 PST, Greg KH wrote:
> > On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> > > 09-diff_rbce
> > > A very basic rules based classification engine for automatically
> > > adding tasks to classes. Also includes an enhanced rules based
> > > classification engine with better per-process delay data and
> > > ability to better monitor class related activities.
> >
> > This one didn't look like it made it to lkml.
> >
> > Oh, and I stopped reviewing the other patches in the series, as the same
> > comments pretty much applied to them :(
>
> Yeah, I checked marc earlier and didn't see it there. I'm making
> the suggested changes now, will resend the whole set when I apply
> and test a bit.
And the questions that I and others had about portions of the code?
Please address them in responses to the messages and don't expect us to
try to pick out if they are still present in the next round of patches
:)
thanks,
greg k-h
On Mon, 29 Nov 2004 20:07:53 PST, Greg KH wrote:
> On Mon, Nov 29, 2004 at 06:48:19PM -0800, Gerrit Huizenga wrote:
> >
> > On Mon, 29 Nov 2004 18:43:21 PST, Greg KH wrote:
> > > On Mon, Nov 29, 2004 at 10:44:49AM -0800, Gerrit Huizenga wrote:
> > > > 09-diff_rbce
> > > > A very basic rules based classification engine for automatically
> > > > adding tasks to classes. Also includes an enhanced rules based
> > > > classification engine with better per-process delay data and
> > > > ability to better monitor class related activities.
> > >
> > > This one didn't look like it made it to lkml.
> > >
> > > Oh, and I stopped reviewing the other patches in the series, as the same
> > > comments pretty much applied to them :(
> >
> > Yeah, I checked marc earlier and didn't see it there. I'm making
> > the suggested changes now, will resend the whole set when I apply
> > and test a bit.
>
> And the questions that I and others had about portions of the code?
> Please address them in responses to the messages and don't expect us to
> try to pick out if they are still present in the next round of patches
> :)
Yeah, yeah, working on it. Will generically apply a number of your
changes. Just sent you a couple of questions about a couple of other
changes.
gerrit
Christoph Hellwig <[email protected]> writes:
[...]
>
> And where's the people who wrote the code? Are people at IBM really
> all anxious cowards these days that can't submit their own code but have
> to abuse a highlevel manager for it.
Once upon a time everybody and his dog (old dogs and puppies alike) at
namesys used to send patches directly to Linus. Which resulted in the
latter being confused in a maze of @namesys.com addresses all similar,
and so he asked Hans to send all patches to him from Hans' address.
Nikita.