ck patch for 2.6.25

Hi,

Anybody done the -ck patch for 2.6.25?

Hugo

Re: ck Digest, Vol 46, Issue 1

Re: Re: ck Digest, Vol 46, Issue 1

Re: Re: ck Digest, Vol 46, Issue 1

Re: ck Digest, Vol 46, Issue 1

Tim Post wrote:
>     On Sat, May 3, 2008 at 10:07 AM, Eschatological Humor
>     <eschatological.humor <at> gmail.com
>     <mailto:eschatological.humor <at> gmail.com>> wrote:
>     Is it safe to unsubscribe to this mailing list yet since there is no
>     longer any furthering development on ck kernel patches?
> 
> 
> The patches are still being worked on by several groups but 
> independently it seems. Usually, when one of them gets it into a new 
> kernel, they'll also announce it here. Last that I saw, some of the 
> Fedora developers were trying to keep it up to date, as well as some 
> people working on suse.
> 
> Since the list is so low volume, it kind of helps to stay subscribed ... 
> or you probably won't find out when more work has been done.
> 

I tried to upgrade the -ck patch to 2.6.25 and ran into problems with 
mm/vmscan.c (line 1200 in the 2.6.24 patch) That routine has changed and 
I don't know what I am doing of course... 

Hugo

Re: Re: ck Digest, Vol 46, Issue 1

On Tue, May 06, 2008 at 02:01:35PM -0500, Hugo Vanwoerkom wrote:

>I tried to upgrade the -ck patch to 2.6.25 and ran into problems with 
>mm/vmscan.c (line 1200 in the 2.6.24 patch) That routine has changed and 
>I don't know what I am doing of course... 

Seems to me that when over a year has passed, and we know how rapidly
the kernel develops, and how major the scheduler changes have been,
the best approach would be to read con's algorithm description, his
ideas for improvement he never implemented and do the thing all over
again.

It's either that or continuous porting over a billion changes,
trying to regression-test every part that seeps through from elsewhere
in the kernel.

--

-- 
mjt

Re: Re: ck Digest, Vol 46, Issue 1

Re: Re: ck Digest, Vol 46, Issue 1

On Sat, May 10, 2008 at 8:52 PM, Markus Törnqvist <mjt <at> nysv.org> wrote:
>  Seems to me that when over a year has passed, and we know how rapidly
>  the kernel develops, and how major the scheduler changes have been,
>  the best approach would be to read con's algorithm description, his
>  ideas for improvement he never implemented and do the thing all over
>  again.
>
>  It's either that or continuous porting over a billion changes,
>  trying to regression-test every part that seeps through from elsewhere
>  in the kernel.

It's both easier and harder than it seems.  If anyone wants to give
this a go, get a git tree of the kernel and I recommend using stgit on
top to import the split-out patches that made up Con's patchset.  They
last applied to 2.6.24 iirc so you may need to specify that tag when
importing.  Next, read Ingo's CFS patchset so you can figure out how
to make sched_sd.c.  The advantage of the split-out patches should be
obvious - you get to run diff through a magnifying glass instead of
trying to absorb all the kernel in your head at once.  People have
been committed for less ;)  Hopefully you'll get to the same stage I
did, where you'll find some interdependency between some patches in
-ck that are non-trivial to implement under CFS and your brain will
explode :)

Then hopefully unlike me you'll continue to have free time to work on it ...

BTW I did send Ingo some ported patches from -ck, things he didn't
feel like implementing upstream (like SCHED_ISO) as some CFS features
make them either redundant or questionable.  It's probably not
worthwhile sending them again, though since iirc it was all the easy
stuff you may like to at least port it anyway a) for completeness b)
to get your mind in the right place and c) for fun :)  BTW Ingo is
great to work with, he's in my top 5 humans to clone 

--

-- 
Matt