Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

> Well, first, please submit this properly (with a proper subject and CC to > linux-pm) > if I'm expected to apply it. > Hi Rafael, Thanks for reminder! A raw read function looks better. And maybe useful for others. Acked-by: Alex Shi > > > > --- >

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

> Well, first, please submit this properly (with a proper subject and CC to > linux-pm) > if I'm expected to apply it. > Hi Rafael, Thanks for reminder! A raw read function looks better. And maybe useful for others. Acked-by: Alex Shi > > > > --- > drivers/base/power/qos.c |

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Thursday, February 23, 2017 09:55:17 PM Alex Shi wrote: > > On 02/23/2017 08:15 PM, Rafael J. Wysocki wrote: > > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > >>> > >>> Its not hard; spinlock_t ends up being a mutex, and this is ran from the > >>> idle thread. What thread do

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Thursday, February 23, 2017 09:55:17 PM Alex Shi wrote: > > On 02/23/2017 08:15 PM, Rafael J. Wysocki wrote: > > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > >>> > >>> Its not hard; spinlock_t ends up being a mutex, and this is ran from the > >>> idle thread. What thread do

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/23/2017 09:08 PM, Mike Galbraith wrote: > On Thu, 2017-02-23 at 13:15 +0100, Rafael J. Wysocki wrote: >> On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: Its not hard; spinlock_t ends up being a mutex, and this is ran from the idle thread. What thread do you

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/23/2017 09:08 PM, Mike Galbraith wrote: > On Thu, 2017-02-23 at 13:15 +0100, Rafael J. Wysocki wrote: >> On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: Its not hard; spinlock_t ends up being a mutex, and this is ran from the idle thread. What thread do you

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/23/2017 08:15 PM, Rafael J. Wysocki wrote: > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: >>> >>> Its not hard; spinlock_t ends up being a mutex, and this is ran from the >>> idle thread. What thread do you think we ought to run when we block >>> idle? >>> >> >> Straight

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/23/2017 08:15 PM, Rafael J. Wysocki wrote: > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: >>> >>> Its not hard; spinlock_t ends up being a mutex, and this is ran from the >>> idle thread. What thread do you think we ought to run when we block >>> idle? >>> >> >> Straight

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Thu, 2017-02-23 at 13:15 +0100, Rafael J. Wysocki wrote: > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > > > > > > Its not hard; spinlock_t ends up being a mutex, and this is ran > > > from the > > > idle thread. What thread do you think we ought to run when we > > > block > >

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Thu, 2017-02-23 at 13:15 +0100, Rafael J. Wysocki wrote: > On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > > > > > > Its not hard; spinlock_t ends up being a mutex, and this is ran > > > from the > > > idle thread. What thread do you think we ought to run when we > > > block > >

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > > > > Its not hard; spinlock_t ends up being a mutex, and this is ran from the > > idle thread. What thread do you think we ought to run when we block > > idle? > > > > Straight right. > Thanks for explanations! :) I overlooked

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wednesday, February 22, 2017 10:55:04 PM Alex Shi wrote: > > > > Its not hard; spinlock_t ends up being a mutex, and this is ran from the > > idle thread. What thread do you think we ought to run when we block > > idle? > > > > Straight right. > Thanks for explanations! :) I overlooked

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 23:36 +0800, Alex Shi wrote: > Sorry. Mike. > What you mean of 'took the zero added cycles option'? :) #ifndef CONFIG_PREEMPT_RT_FULL ... #endif I waved my magic ifdef wand, and poof, they disappeared :) -Mike

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 23:36 +0800, Alex Shi wrote: > Sorry. Mike. > What you mean of 'took the zero added cycles option'? :) #ifndef CONFIG_PREEMPT_RT_FULL ... #endif I waved my magic ifdef wand, and poof, they disappeared :) -Mike

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/22/2017 11:03 PM, Mike Galbraith wrote: >> > >> > Yes, the dev_pm_qos_read_value() using a power.lock, that is right for >> > normal device. >> > But as to this cpu here, the lock isn't necessary. >> > >> > Hi Rafael, >> > Is this fix ok? > That's what I was gonna do, but then figured

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On 02/22/2017 11:03 PM, Mike Galbraith wrote: >> > >> > Yes, the dev_pm_qos_read_value() using a power.lock, that is right for >> > normal device. >> > But as to this cpu here, the lock isn't necessary. >> > >> > Hi Rafael, >> > Is this fix ok? > That's what I was gonna do, but then figured

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 22:53 +0800, Alex Shi wrote: > cc Rafael. > > > On 02/22/2017 09:12 PM, 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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 22:53 +0800, Alex Shi wrote: > cc Rafael. > > > On 02/22/2017 09:12 PM, 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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

> > Its not hard; spinlock_t ends up being a mutex, and this is ran from the > idle thread. What thread do you think we ought to run when we block > idle? > Straight right. Thanks for explanations! :)

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

> > Its not hard; spinlock_t ends up being a mutex, and this is ran from the > idle thread. What thread do you think we ought to run when we block > idle? > Straight right. Thanks for explanations! :)

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

cc Rafael. On 02/22/2017 09:12 PM, 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. > > Also, yeah, reading a s32 should

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

cc Rafael. On 02/22/2017 09:12 PM, 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. > > Also, yeah, reading a s32 should

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

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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, Feb 22, 2017 at 10:31:26PM +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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, Feb 22, 2017 at 10:31:26PM +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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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. Also, yeah, reading a s32 should not need no locking, but there's a bunch of pointer chases in between

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

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. Also, yeah, reading a s32 should not need no locking, but there's a bunch of pointer chases in between

9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

Hi, Do we really need a spinlock for that in the idle loop? -Mike

9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

Hi, Do we really need a spinlock for that in the idle loop? -Mike