Re: v2.6.21.5-rt19

[Ingo Molnar <mingo@elte.hu>]

* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> > > Changes since 2.6.21.5-rt18:
> > >
> > > - Fixed a nasty and hard to track down slowness / boot problem on SMP
> > > machines with CONFIG_NOHZ enabled. The problem was caused by the timer
> > > wheel base lock held during the get_next_timer_interrupt() call in the
> > > idle path, which eventually led to a bogus PI boosting of the idle task
> > > and in consequence a stale wrong scheduler selection for the affected idle
> > > task.
> > >
> > > Kudos to Carsten Emde, who patiently and meticulously isolated the
> > > problem and provided the traces, which allowed to identify the root cause.
> > >
> > > Problem solution: Prevent idle task boosting

> > Maybe someone remember me whining about troubles with 2.6.21-rt2..18 
> > on my Core2 T7200 laptop (fujitsu-siemens amilo i1520).
> > 
> > Althought I'm still with my fingers crossed, I can tell the good 
> > news are that 2.6.21.5-rt19 (and -rt20) does behave far better now 
> > on the very same box.
> 
> Yes, it works much better indeed...
> 
> Ingo: is there a place where I can read about the changes in different 
> rtxx releases? What is new/better/fixed in rt20? (I see scheduler 
> stuff in a diff from rt19 to rt20 but I don't really know what it 
> means).

and rt18 was a -rt-only NOHZ fix, that bug got introduced in rt11 when 
CFS was merged.

i _think_ Rui might have seen two separate problems. Perhaps by the time 
we fixed the first problem (which Rui saw since -rt2) we introduced the 
other one via -rt11 - which then got fixed in -rt19.

btw., we'd love to get more feedback regarding CFS. CFS is a completely 
new scheduler for Linux. It has a design centered around keeping 
application latencies down, so it is ultimately real-time friendly, and 
it should also make things work better for desktop-ish and audio-ish 
stuff as well. (even under SCHED_OTHER)

So it would be nice if you could keep an extra eye on any scheduling 
artifacts or regressions, and make sure your favorite workload is still 
handled by the Linux scheduler in the utmost best way. I'd like to hear 
about any sort of "scheduling behavior / interactivity" regression you 
might see, relative to the vanilla kernel. Or if you can see no such 
problems then a line of "it works as well as the previous scheduler" is 
important info to us too. Thanks!

	Ingo