[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160217161320.GL32705@phenom.ffwll.local>
Date: Wed, 17 Feb 2016 17:13:21 +0100
From: Daniel Vetter <daniel@...ll.ch>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Oleg Nesterov <oleg@...hat.com>,
Intel graphics driver community testing & development
<intel-gfx@...ts.freedesktop.org>,
Linux kernel development <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
David Hildenbrand <dahi@...ux.vnet.ibm.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>,
Chris Wilson <chris@...is-wilson.co.uk>,
Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference
counting
On Wed, Feb 17, 2016 at 03:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 02:47:31PM +0200, Joonas Lahtinen wrote:
> > On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> > > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > > > Quoting my original patch;
> > > >
> > > > "See the Bugzilla link for more details.
> > >
> > > If its not in the Changelog it doesn't exist. Patches should be self
> > > contained and not refer to external sources for critical information.
> >
> > The exact locking case in CPUfreq drivers causing a splat is described
> > in the patch. Details were already included, that's why term "more
> > details" was used.
>
> Barely. What was not described was why you went to tinker with the
> hotplug lock instead of sanitizing cpufreq. Nor why your chosen solution
> is good.
>
> > This is not exactly taking us closer to a fix,
>
> Why you think we can discuss fixes if you've not actually described your
> problem is beyond me.
Can we please stop the petty-fights while figuring out how to work out a
solution here, thanks.
And for context we're hitting this on CI in a bunch of our machines, which
means no more lockdep checking for us. Which is, at least for me, pretty
serious, and why we're throwing complete cpu-anything newbies at that code
trying to come up with some solution to unblock our CI efforts for the
intel gfx driver. Unfortunately our attempts at just disabling lots of
Kconfig symbols proofed futile, so ideas to avoid all that code highly
welcome.
As soon as CI stops hitting this we'll jump out of your inbox, if you want
so.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists