On Sat, 2007-07-07 at 11:24 +0200, Ingo Molnar wrote:

* Fernando Lopez-Lezcano [off-list ref] wrote:

quoted

quoted

quoted

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

quoted

quoted

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.

Ahh, CFS is now part of rt, I was obviously not paying attention... I'm
really trying to provide a "stable" rt kernel for audio usage and
including another subsystem into rt is - IMHO - not going to help.
What's the chance of splitting things?

btw., we'd love to get more feedback regarding CFS. CFS is a completely 
new scheduler for Linux. 

Then I'd rather have it separate from rt. 

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)

Maybe this is CFS related? (tail of a thread in the Planet CCRMA mailing
list):

On Sun, 2007-07-08 at 15:26 -0400, Hector Centeno wrote:

Ok, so just to confirm, that 2.6.21-0182.rt19.1.fc7.ccrmart works fine
on my desktop but on my laptop it makes Firefox and Tomboy to crash.
On the same laptop using 2.6.21-0182.rt17.1.fc7.ccrmart there is no
problem.

Cheers,

Hector


On 7/7/07, Hector Centeno [off-list ref] wrote:
        Hi Fernando,
        
        I do have Flash installed but for me Firefox crashes when
        trying to
        access gmail (which AFAIK doesn't use Flash, does it?). Right
        now
        Firefox is frozen and I'm typing this email using Konkeror (in
        Gnome). 
        This is ps' output:
        
        hector    3595  1.1  2.2 194352 46336 ?        D    16:25
        0:03
        /usr/lib/firefox-2.0.0.4/firefox-bin
        
        I think the problem is not present in my Desktop but I have to
        double 
        check. In the same laptop using the stock fedora kernel both
        Tomboy
        and Firefox work fine. My laptop has a centrino duo processor,
        2 gigs
        of ram and the Inte GMA950 graphics chip.
        
        Hector

I managed to completely hang firefox (fc7) with flash 9 installed
(unkillable even with -9). Does not seem to happen with flash 7. Have
not tried yet with gmail and flash uninstalled. I'll try to strace it to
see when/why it hangs. 

-- Fernando

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!