Re: [PATCH] CFS scheduler: documentation about scheduling policies

[Ingo Molnar]

* Martin Steigerwald <ms@xxxxxxxxx> wrote:

> Am Dienstag, 23. September 2008 schrieb Ingo Molnar:
> > * Martin Steigerwald <ms@xxxxxxxxx> wrote:
> > > > please use -p1 to create patches - or since you've just set up the
> > > > tip/master tracking, do something like:
> > >
> > > Okay, lets see how this works out.
> > >
> > > ---
> > > From a57581d4ec3b13f63920b89c336ac9c93c6cf9f0 Mon Sep 17 00:00:00 2001
> > > From: Martin Steigerwald <ms@xxxxxxxxx>
> > > Date: Tue, 23 Sep 2008 13:45:46 +0200
> > > Subject: [PATCH] CFS: Documentation about scheduling policies
> >
> > Applied to tip/sched/devel, merged it into tip/master and pushed the
> > result out - thanks Martin.
> >
> > this was a perfect patch :)
> 
> Thanks. Now I can learn how I can update my local tip-master ;-). 
> Hmmm, git pull seemed to do the trick although it did not touch 
> Documentation/scheduler/sched-design-CFS.txt again. Seems it detected 
> that I applied the patch I sent you already.

yes.

the best way to update is to have tip as a remote and to update via 'git 
remote update'. Then you can do "git merge tip/master" - or if this does 
not work (tip/master is an integration branch and has to be reset 
occasionally) then you can do a 'git-reset --hard tip/master' to switch 
over to the new tree.

NOTE: a hard reset means you'll lose local commits. If you want to carry 
them over then do something like:

 git rebase -i --onto tip/master 123412341234

where 123412341234 is the sha1 of the previous tip/master you based your 
local changes on.

> Will it be in 2.6.28 or even in 2.6.27? 8-)

yes, it's queued up for v2.6.28. For v2.6.27 we [in -tip] dont do 
documentation updates starting at around -rc4 or so (to reduce the 
upstream churn).

> Looking forward to further documentation patches - these can't break 
> any code ;-).

definitely ;-)

	Ingo
--
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/