On Fri, 2012-09-14 at 21:15 -0700, Linus Torvalds wrote: > We don't do random crazy "use another scheduler" to hide problems with > the default one.
I was proposing a diagnostic. > > And since you are the author of the regressing patch, and don't seem > to treat the regression as something serious, I really see no > alternative to just reverting it. Wow, I don't know how you obtained that impression, but fine, nuke it. > Linus > > On Sep 14, 2012 9:11 PM, "Mike Galbraith" <efa...@gmx.de> wrote: > On Fri, 2012-09-14 at 23:27 +0200, Borislav Petkov wrote: > > (Adding everybody to CC and leaving the below for > reference.) > > > > Guys, > > > > as Nikolay says below, we have a regression in 3.6 with > pgbench's > > benchmark in postgresql. > > > > I was able to reproduce it on another box here and did a > bisection run. > > It pointed to the commit below. > > > > And yes, reverting that commit fixes the issue here. > > My wild (and only) theory is that this is userspace spinlock > related. > If so, starting the server and benchmark SCHED_BATCH should > not only > kill the regression, but likely improve throughput as well. > > -Mike > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
