Fernando Lopez-Lezcano wrote:
On Sat, 2007-07-07 at 11:24 +0200, Ingo Molnar wrote:
* Fernando Lopez-Lezcano <[email protected]> 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.
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 <[email protected]> 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).
Firefox with flash 9 does not work good , there are a lot bugs reported
about ( just google ) and it hangs on vanilla or
whatever other kernels as well. Not only Firefox but also Swiftfox,
Opera, Epiphany etc.
The most time Firefox dies when you use flash 9 and close a window or a tab.
Does not seem to happen with flash 7.
Yes flash 7 is fine.
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!
Regards,
Gabriel C
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
