All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel C <nix.or.die@googlemail.com>
To: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Cc: Ingo Molnar <mingo@elte.hu>, Rui Nuno Capela <rncbc@rncbc.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	RT-Users <linux-rt-users@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"jcaceres@ccrma.Stanford.EDU" <jcaceres@ccrma.Stanford.EDU>,
	Carsten Emde <carsten.emde@osadl.org>
Subject: Re: v2.6.21.5-rt19
Date: Mon, 09 Jul 2007 01:42:48 +0200	[thread overview]
Message-ID: <46917678.70700@googlemail.com> (raw)
In-Reply-To: <1183934205.11854.11.camel@cmn3.stanford.edu>

Fernando Lopez-Lezcano wrote:
> On Sat, 2007-07-07 at 11:24 +0200, Ingo Molnar wrote:
>   
>> * 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.
>>     
>
> 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 <hcengar@gmail.com> 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

  parent reply	other threads:[~2007-07-08 23:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-04 20:49 v2.6.21.5-rt19 Thomas Gleixner
2007-07-06 14:10 ` v2.6.21.5-rt19 Rui Nuno Capela
2007-07-06 21:49   ` v2.6.21.5-rt19 Fernando Lopez-Lezcano
2007-07-07  9:15     ` v2.6.21.5-rt19 Ingo Molnar
2007-07-07  9:24     ` v2.6.21.5-rt19 Ingo Molnar
2007-07-08 22:36       ` v2.6.21.5-rt19 Fernando Lopez-Lezcano
2007-07-08 22:50         ` v2.6.21.5-rt19 Fernando Lopez-Lezcano
2007-07-08 23:42         ` Gabriel C [this message]
2007-07-09  3:53           ` v2.6.21.5-rt19 Fernando Pablo Lopez-Lezcano
2007-07-09  5:08             ` v2.6.21.5-rt19 (sched_getaffinity?) Fernando Lopez-Lezcano
2007-07-17 19:32               ` Ingo Molnar
2007-07-17 19:47                 ` Fernando Lopez-Lezcano
2007-07-17 19:56                 ` Fernando Lopez-Lezcano
2007-07-17 20:12                   ` Ingo Molnar
2007-07-17 21:41                     ` Fernando Lopez-Lezcano
2007-07-17 23:51                     ` Fernando Lopez-Lezcano
2007-07-18  7:18                       ` Ingo Molnar
2007-07-18 13:21                         ` Paul E. McKenney
2007-07-18 18:02                         ` Fernando Lopez-Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46917678.70700@googlemail.com \
    --to=nix.or.die@googlemail.com \
    --cc=carsten.emde@osadl.org \
    --cc=jcaceres@ccrma.Stanford.EDU \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nando@ccrma.Stanford.EDU \
    --cc=rncbc@rncbc.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.