[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1172566453.7009.28.camel@Homer.simpson.net>
Date: Tue, 27 Feb 2007 09:54:13 +0100
From: Mike Galbraith <efault@....de>
To: Ingo Molnar <mingo@...e.hu>
Cc: Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Adrian Bunk <bunk@...sta.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"David P. Reed" <dpreed@...d.com>,
Ayaz Abdulla <aabdulla@...dia.com>, jgarzik@...ox.com,
netdev@...r.kernel.org,
Albert Hopkins <kernel@...duk.letterboxes.org>,
Bob Tracy <rct@...rkin.frus.com>,
Mark Brown <broonie@...ena.org.uk>,
"Michael S. Tsirkin" <mst@...lanox.co.il>
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 2)
On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> * Michal Piotrowski <michal.k.k.piotrowski@...il.com> wrote:
>
> > Thomas Gleixner napisaĆ(a):
> > > Adrian,
> > >
> > > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> > >> Subject : kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
> > >> References : http://lkml.org/lkml/2007/2/16/346
> > >> Submitter : Michal Piotrowski <michal.k.k.piotrowski@...il.com>
> > >> Handled-By : Thomas Gleixner <tglx@...utronix.de>
> > >> Status : problem is being debugged
> > >
> > > The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
> > > problem with the SMT scheduler. See below.
> > >
> > >> Subject : BUG: soft lockup detected on CPU#0
> > >> NOHZ: local_softirq_pending 20 (SMT scheduler)
> > >> References : http://lkml.org/lkml/2007/2/20/257
> > >> Submitter : Michal Piotrowski <michal.k.k.piotrowski@...il.com>
> > >> Handled-By : Thomas Gleixner <tglx@...utronix.de>
> > >> Ingo Molnar <mingo@...e.hu>
> > >> Status : problem is being debugged
> > >
> > > Patch available, not confirmed yet.
> > >
> >
> > I can confirm that the bug is fixed (over 20 hours of testing should
> > be enough).
>
> thanks alot! I think this thing was a long-term performance/latency
> regression in HT scheduling as well.
Agreed.
I was recently looking at that spot because I found that niced tasks
were taking latency hits, and disabled it, which helped a bunch. I also
can't understand why it would be OK to interleave a normal task with an
RT task sometimes, but not others.. that's meaningless to the RT task.
IMHO, SMT scheduling should be a buyer beware thing. Maximizing your
core utilization comes at a price, but so does disabling it, so I think
letting the user decide what he wants is the right thing to do.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists