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

[Ingo Molnar <mingo@elte.hu>]

* Martin Steigerwald <ms@teamix.de> wrote:

> Am Dienstag, 23. September 2008 schrieb Ingo Molnar:
> > * Martin Steigerwald <ms@teamix.de> wrote:
> > > The documentation about the CFS scheduler is scarse when it comes to
> > > scheduling policies. This patch adds a chapter about the scheduling
> > > policies it supports. Peter Zijlstra provided most of the information for
> > > it in
> > >
> > > http://marc.info/?l=linux-kernel&m=122210038326356&w=2
> > >
> > > This patch is based on 2.6.27-rc7.
> > >
> > > Signed-off-by: Martin Steigerwald <ms@teamix.de>
> >
> > looks good to me - but could you please do the patch against the latest
> > scheduler tree, which has already updated this file (and which made your
> > patch not apply cleanly):
> >
> >   http://people.redhat.com/mingo/tip.git/README
> 
> Should I use 
> 
> checkout -b tip-latest tip/master
> 
> as described in the README or tip/sched/devel or even something else?

tip/master should be fine - it has sched/devel integrated. I'll sort out 
any cross-topic impact.

> I am new to git. I know Bazaar quite well however, so I am not 
> compeltely new to DVCS.

the -tip tree, maintained by Thomas Gleixner, H. Peter Anvin and myself 
is a "forest of trees" based on Linus's very latest -git tree. Currently 
it's a collection of more than 180 topic trees. Most topic trees are 
based on upstream -git, some topic trees are based on each other and 
tip/master has them all integrated together.

there are a few main themes within -tip: tip/x86/* are all the currently 
active x86 topics - all changes that are for v2.6.28. tip/sched/* are 
the pending scheduler changes. tip/timers/* are timer changes, 
tip/tracing/* are tracing patches, etc.

Unless you are a high-volume patch submitter or a maintainer of a given 
topic tree it's not necessary for you to know/follow/interpret the 
internal structure of -tip - you can send patches against tip/master and 
we'll sort the patch out into the right topic branch. (and resolve 
conflicts, if any)

Generally tip/master is not supposed to break in any way anytime: it 
must build and boot on all hardware, no ifs and when. So it's not a 
development tree in the classic sense, i.e. temporary breakages and 
user-visible transition periods are not accepted. We do a lot of 
automated testing against tip/master so it should be fine for daily 
desktop use and daily development work. I use latest tip/master on about 
7 x86 boxes at the moment.

The individual topic trees are development trees, and might contain bugs 
at times - but we filter those out and only represent/merge a 
known-stable version of each sub-tree in tip/master.

At least that's the theory - it's still a high-flux tree with multiple 
updates every day and has an average of ~15 new commits added per day, 
24/7. If you see a problem with it then please report it.

	Ingo