[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1487774800.4487.15.camel@gmx.de>
Date: Wed, 22 Feb 2017 15:46:40 +0100
From: Mike Galbraith <efault@....de>
To: Alex Shi <alex.shi@...aro.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency
consideration
On Wed, 2017-02-22 at 22:31 +0800, Alex Shi wrote:
>
> On 02/22/2017 09:19 PM, Mike Galbraith wrote:
> > On Wed, 2017-02-22 at 14:12 +0100, Peter Zijlstra wrote:
> > > On Wed, Feb 22, 2017 at 01:56:37PM +0100, Mike Galbraith wrote:
> > > > Hi,
> > > >
> > > > Do we really need a spinlock for that in the idle loop?
> > >
> > > Urgh, that's broken on RT, you cannot schedule the idle loop.
> >
> > That's what made me notice the obnoxious little bugger.
>
> Hi Mike,
>
> Sorry for this bug. Guess the rt_spin_lock call some function in
> rtmutex.c:995. Could you like to show me how to reproduce this bug?
Yeah, spinlock_t is transmogrified into an rtmutex in RT trees. No
need to reproduce, if you just make the lock go away, RT trees will
become happy camper again, and NONRT trees won't have to feed yet
another an cycle sucking lock in the fastpath.
-Mike
Powered by blists - more mailing lists