Re: [ckrm-tech] Re: [PATCH] CKRM: 0/10 Class Based Kernel Resource Management

[Gerrit Huizenga]

On Fri, 03 Dec 2004 16:40:34 PST, Andrew Morton wrote:
> "Marc E. Fiuczynski" <mef@xxxxxxxxxxxxxxxx> wrote:
> >
> > I integrated CKRM with the kernel used by PlanetLab (www.planet-lab.org),
> > and I believe we (PlanetLab) are the first to use CKRM in a production
> > setting.
> > ...
> > Hope this helps.
> 
> It does, thanks.
> 
> A concern which I have about the CKRM implementation is that the patches
> which have been sent out appear to be simply the "core" of CKRM, plus
> minimally-intrusive hooks.  I have the impression that this core will not
> be terribly useful to real-world users and that follow-on patches will be
> required to add more functionality and to wire up more instrumentation and
> control points.
> 
> I would not like to be in a situation where we merge the "core" patch, but
> the as-yet-unseen follow-on patches which make CKRM useful and complete end
> up creating a big unmaintainable mess.  We end up not wanting to go
> forwards and being unable to go backwards.
> 
> IOW: I think we need to see a reasonably-close-to-final implementation of
> CKRM before we can take it much further.

Understood.  We do have a more complete set of patches floating around,
although most are ported to an existing distro rather than set for
current mainline adoption.  But if we can get general consensus on
the patches (once I finish the current round of cleanup and testing),
we do have work in memory management, IO scheduling, and even CPU
scheduling (the latter being the most debatable for mainline acceptance
given the rate of scheduler replacements in recent past) that are
being used today.

We can dump the current, raw distro patches or the rest of the e16
patch set from ckrm-tech on you although I believe they will need
some significant review/modification to be mainline acceptable yet.
One big problem is that these changes are somewhat hard to maintain as
distinct from mainline and yet remain relatively current.  There are
several developers working in distinct areas and each area moves at
its own pace.  Hence, I'd like to get to a more stable -mm compatible
core, and build up from there.  As we see that the entire set approaches
stability/utility, we can push from the core up through the working set
of resource controllers.

If getting you a set of patches for general concept review as based
on a current distro would help, just say the word.  However, getting
those up to current mainline, integrated with each other and fully
tested (while holding their development stable long enough to do that)
is the requirement, well, that will take us a fair bit longer.

Part of the goal of this posting was to start to stabilize a core
and improve on it, rather than try to deliver an entire project as a
moderately large set of changes as a fait accompli.  And, we are more
than willing to continue to tweak and tune this to be generally useful
to a wider audience, even though we have a set that works well for
some groups needing better workload management.

So, Andrew, can you clarify how much we need to put in your hands, how
well tested it needs to be and how clean and current the entire set needs
to be before this is ready for -mm testing?

gerrit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/