Re: [ANNOUNCE] 3.14-rt1

[Mike Galbraith]

On Wed, 2014-04-30 at 09:43 +0200, Mike Galbraith wrote: 
> On Tue, 2014-04-29 at 20:13 -0400, Steven Rostedt wrote: 
> > On Tue, 29 Apr 2014 07:21:09 +0200
> > Mike Galbraith <umgwanakikbuti@xxxxxxxxx> wrote:
> > 
> > > On Mon, 2014-04-28 at 16:37 +0200, Mike Galbraith wrote: 
> > > 
> > > > > Seems that migrate_disable() must be called before taking the lock as
> > > > > it is done in every other location.
> > > > 
> > > > And for tasklist_lock, seems you also MUST do that prior to trylock as
> > > > well, else you'll run afoul of the hotplug beast.
> > > 
> > > Bah.  Futzing with dmesg while stress script is running is either a very
> > > bad idea, or a very good test.  Both virgin 3.10-rt and 3.12-rt with new
> > > bugs squashed will deadlock.
> > > 
> > > Too bad I kept on testing, I liked the notion that hotplug was solid ;-)
> > 
> > I was able to stress cpu hotplug on 3.12-rt after applying the
> > following patch.
> > 
> > If there's no complaints about it. I'm going to add this to the 3.12-rt
> > stable tree. As without it, it fails horribly with the cpu hotplug
> > stress test, and I wont release a stable kernel that does that.
> 
> My local boxen are happy, 64 core box with 14-rt seems happy as well,
> though I couldn't let it burn for long.

And 3.12 looks stable on 64 core DL980 as well.  (If it survived a 24
hour busy+stress session I'd still likely fall outta my chair though)

My kinda sorta 3.12-rt enterprise to be kernel wasn't stable on DL980,
while appearing just fine on small boxen, which made me suspect that
there was still a big box something lurking, only raising its ugly head
in the fatter kernel.  That wasn't an rt problem after all, someone in
enterprise land just didn't stack their goody pile quite high enough
while wedging upstream into the stable base kernel, which bent rt.

The End.. I hope.  I've had enough hotplug entertainment for a while.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/