On Mon, Mar 23, 2015 at 08:37:42AM -0700, Paul E. McKenney wrote:
> On Mon, Mar 23, 2015 at 02:00:41PM +, Russell King - ARM Linux wrote:
> > On Mon, Mar 23, 2015 at 06:21:33AM -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 23, 2015 at 12:55:45PM +, Russell King - ARM Linux wrote:
> > > >
On Mon, Mar 23, 2015 at 02:00:41PM +, Russell King - ARM Linux wrote:
> On Mon, Mar 23, 2015 at 06:21:33AM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 23, 2015 at 12:55:45PM +, Russell King - ARM Linux wrote:
> > > What if the cpu_hotplug_state for the CPU changes between reading it
> >
On Mon, Mar 23, 2015 at 06:21:33AM -0700, Paul E. McKenney wrote:
> On Mon, Mar 23, 2015 at 12:55:45PM +, Russell King - ARM Linux wrote:
> > What if the cpu_hotplug_state for the CPU changes between reading it
> > testing its value, and then writing it, or do we guarantee that it
> > can't cha
On Mon, Mar 23, 2015 at 12:55:45PM +, Russell King - ARM Linux wrote:
> On Sun, Mar 22, 2015 at 04:30:57PM -0700, Paul E. McKenney wrote:
> > On Wed, Feb 25, 2015 at 05:05:05PM -0800, Paul E. McKenney wrote:
> > > On Wed, Feb 25, 2015 at 03:16:59PM -0500, Nicolas Pitre wrote:
> > > > On Wed, 25
On Sun, Mar 22, 2015 at 04:30:57PM -0700, Paul E. McKenney wrote:
> On Wed, Feb 25, 2015 at 05:05:05PM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 25, 2015 at 03:16:59PM -0500, Nicolas Pitre wrote:
> > > On Wed, 25 Feb 2015, Nicolas Pitre wrote:
> > >
> > > > On Wed, 25 Feb 2015, Russell King -
On Wed, Feb 25, 2015 at 05:05:05PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 25, 2015 at 03:16:59PM -0500, Nicolas Pitre wrote:
> > On Wed, 25 Feb 2015, Nicolas Pitre wrote:
> >
> > > On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
> > >
> > > > We could just use the spin-and-poll solutio
On Thu, 26 Feb 2015, Daniel Thompson wrote:
> On Wed, 2015-02-25 at 11:47 -0500, Nicolas Pitre wrote:
> > On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
> >
> > > On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> > > > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul
On Wed, 2015-02-25 at 11:47 -0500, Nicolas Pitre wrote:
> On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
>
> > On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> > > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > > > Works for me, assuming no h
On Wed, Feb 25, 2015 at 03:16:59PM -0500, Nicolas Pitre wrote:
> On Wed, 25 Feb 2015, Nicolas Pitre wrote:
>
> > On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
> >
> > > We could just use the spin-and-poll solution instead of an IPI, but
> > > I really don't like that - when you see the com
On Wed, 25 Feb 2015, Nicolas Pitre wrote:
> On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
>
> > We could just use the spin-and-poll solution instead of an IPI, but
> > I really don't like that - when you see the complexity needed to
> > re-initialise it each time, it quickly becomes very y
On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
> On Wed, Feb 25, 2015 at 11:47:48AM -0500, Nicolas Pitre wrote:
> > I completely agree with the r/w spinlock. Something like this ought to
> > be sufficient to make gic_raise_softirq() reentrant which is the issue
> > here, right? I've been
On Wed, Feb 25, 2015 at 11:47:48AM -0500, Nicolas Pitre wrote:
> I completely agree with the r/w spinlock. Something like this ought to
> be sufficient to make gic_raise_softirq() reentrant which is the issue
> here, right? I've been stress-testing it for a while with no problems
> so far.
No.
On Wed, 25 Feb 2015, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > > Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> >
> > Sigh... I kind'a
On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
>
> Sigh... I kind'a new it wouldn't be this simple. The gic code which
> actually r
On Fri, Feb 13, 2015 at 05:21:41PM +, Mark Rutland wrote:
> On Fri, Feb 13, 2015 at 04:27:25PM +, Russell King - ARM Linux wrote:
> > If it happens after __cpu_disable(), then that's a problem: the system
> > will have gone through all the expensive preparation by that time to
> > shut the
On Fri, Feb 13, 2015 at 04:27:25PM +, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 03:52:08PM +, Mark Rutland wrote:
> > > @@ -194,10 +195,6 @@ int __cpu_disable(void)
> > > unsigned int cpu = smp_processor_id();
> > > int ret;
> > >
> > > - ret = platform_cpu_disable(cpu
On 02/13/15 07:52, Mark Rutland wrote:
> @@ -194,10 +195,6 @@ int __cpu_disable(void)
> unsigned int cpu = smp_processor_id();
> int ret;
>
> - ret = platform_cpu_disable(cpu);
> - if (ret)
> - return ret;
> For PSCI 0.2+ I was hoping to hook the MIGRATE logic in h
On Fri, Feb 13, 2015 at 03:52:08PM +, Mark Rutland wrote:
> > @@ -194,10 +195,6 @@ int __cpu_disable(void)
> > unsigned int cpu = smp_processor_id();
> > int ret;
> >
> > - ret = platform_cpu_disable(cpu);
> > - if (ret)
> > - return ret;
>
> For PSCI 0.2+ I was hoping
[...]
> > Aside: For that last row we really should be setting cpu->hotpluggable
> > in struct cpu based on what cpu_ops::cpu_disable returns (from what I
> > can tell we use that op to indicate if a CPU can be hotplugged).
> >
>
> There's a patch for that (tm).
>
> 8<
>
> From: Stephen
On Tue, Feb 10, 2015 at 08:48:18PM +, Stephen Boyd wrote:
> On 02/10/15 07:14, Mark Rutland wrote:
> > On Tue, Feb 10, 2015 at 01:24:08AM +, Stephen Boyd wrote:
> >> On 02/05/15 08:11, Russell King - ARM Linux wrote:
> >>> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
>
On 02/10/15 13:49, Stephen Boyd wrote:
>>> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
>>> index fe0386c751b2..4d213b24db60 100644
>>> --- a/arch/arm/kernel/smp.c
>>> +++ b/arch/arm/kernel/smp.c
>>> @@ -174,18 +174,19 @@ static int platform_cpu_kill(unsigned int cpu)
>>> return 1
On 02/10/15 13:15, Russell King - ARM Linux wrote:
> On Tue, Feb 10, 2015 at 01:04:30PM -0800, Stephen Boyd wrote:
>> From: Stephen Boyd
>> Subject: [PATCH] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
>>
>> Writes to /sys/.../cpuX/online fail if we determine the platform
>> doesn't
On Tue, Feb 10, 2015 at 01:04:30PM -0800, Stephen Boyd wrote:
> From: Stephen Boyd
> Subject: [PATCH] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
>
> Writes to /sys/.../cpuX/online fail if we determine the platform
> doesn't support hotplug for that CPU. Let's figure this out
> bef
On 02/10/15 12:48, Stephen Boyd wrote:
> On 02/10/15 07:14, Mark Rutland wrote:
>> On Tue, Feb 10, 2015 at 01:24:08AM +, Stephen Boyd wrote:
>>> On 02/05/15 08:11, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> Works for me, assuming
On Tue, Feb 10, 2015 at 03:14:16PM +, Mark Rutland wrote:
> That sounds about right, though surely cache flush is irrelevant w.r.t.
> publishing of the unlock? The dsb(ishst) in the unlock path will ensure
> that the write is visibile prior to the second flush_cache_louis().
>
> That said, we
On 02/10/15 07:14, Mark Rutland wrote:
> On Tue, Feb 10, 2015 at 01:24:08AM +, Stephen Boyd wrote:
>> On 02/05/15 08:11, Russell King - ARM Linux wrote:
>>> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
On 02/10/15 07:41, Russell King - ARM Linux wrote:
> On Mon, Feb 09, 2015 at 05:24:08PM -0800, Stephen Boyd wrote:
>
>
>> Maybe we can do the same thing here by using a
>> spinlock for synchronization between the IPI handler and the dying CPU?
>> So lock/unlock around the IPI sending from the dying
On Mon, Feb 09, 2015 at 05:24:08PM -0800, Stephen Boyd wrote:
> On 02/05/15 08:11, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> >> Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> > Sigh... I kind'a new it wouldn't be th
On Tue, Feb 10, 2015 at 01:24:08AM +, Stephen Boyd wrote:
> On 02/05/15 08:11, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> >> Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> > Sigh... I kind'a new it wouldn't be th
On Mon, Feb 09, 2015 at 06:05:55PM -0800, Stephen Boyd wrote:
> On 02/09/15 17:37, Paul E. McKenney wrote:
> > On Mon, Feb 09, 2015 at 05:24:08PM -0800, Stephen Boyd wrote:
> >> On 02/05/15 08:11, Russell King - ARM Linux wrote:
> >>> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote
On 02/09/15 17:37, Paul E. McKenney wrote:
> On Mon, Feb 09, 2015 at 05:24:08PM -0800, Stephen Boyd wrote:
>> On 02/05/15 08:11, Russell King - ARM Linux wrote:
>>> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
Works for me, assuming no hidden uses of RCU in the IPI code.
On Mon, Feb 09, 2015 at 05:24:08PM -0800, Stephen Boyd wrote:
> On 02/05/15 08:11, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> >> Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> > Sigh... I kind'a new it wouldn't be th
On 02/05/15 08:11, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
>> Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> Sigh... I kind'a new it wouldn't be this simple. The gic code which
> actually raises the IPI takes a raw s
On Thu, Feb 05, 2015 at 05:34:40PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 09:02:28AM -0800, Paul E. McKenney wrote:
> > On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> > > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > > >
On Thu, Feb 05, 2015 at 09:02:28AM -0800, Paul E. McKenney wrote:
> On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > > Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
> >
> > Sigh.
On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> > Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
>
> Sigh... I kind'a new it wouldn't be this simple. The gic code which
> actually r
On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote:
> Works for me, assuming no hidden uses of RCU in the IPI code. ;-)
Sigh... I kind'a new it wouldn't be this simple. The gic code which
actually raises the IPI takes a raw spinlock, so it's not going to be
this simple - there's a
On Thu, Feb 05, 2015 at 10:50:35AM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> > The complete() should not be used on offlined CPU. Rewrite the
> > wait-complete mechanism with wait_on_bit_timeout().
>
> Yuck.
>
> I think that th
On Thu, Feb 05, 2015 at 11:28:05AM +, Mark Rutland wrote:
> Hi Russell,
>
> On Thu, Feb 05, 2015 at 10:50:35AM +, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> > > The complete() should not be used on offlined CPU. Rewrite the
>
Hi Russell,
On Thu, Feb 05, 2015 at 10:50:35AM +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> > The complete() should not be used on offlined CPU. Rewrite the
> > wait-complete mechanism with wait_on_bit_timeout().
>
> Yuck.
>
> I
On Thu, Feb 05, 2015 at 12:00:58PM +0100, Krzysztof Kozlowski wrote:
> On czw, 2015-02-05 at 10:50 +, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> > > The complete() should not be used on offlined CPU. Rewrite the
> > > wait-complete
On czw, 2015-02-05 at 10:50 +, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> > The complete() should not be used on offlined CPU. Rewrite the
> > wait-complete mechanism with wait_on_bit_timeout().
>
> Yuck.
>
> I think that the IPI i
On czw, 2015-02-05 at 10:53 +, Mark Rutland wrote:
> On Thu, Feb 05, 2015 at 10:14:30AM +, Krzysztof Kozlowski wrote:
> > The complete() should not be used on offlined CPU. Rewrite the
> > wait-complete mechanism with wait_on_bit_timeout().
> >
> > The CPU triggering hot unplug (e.g. CPU0)
On Thu, Feb 05, 2015 at 10:14:30AM +, Krzysztof Kozlowski wrote:
> The complete() should not be used on offlined CPU. Rewrite the
> wait-complete mechanism with wait_on_bit_timeout().
>
> The CPU triggering hot unplug (e.g. CPU0) will loop until some bit is
> cleared. In each iteration schedul
On Thu, Feb 05, 2015 at 11:14:30AM +0100, Krzysztof Kozlowski wrote:
> The complete() should not be used on offlined CPU. Rewrite the
> wait-complete mechanism with wait_on_bit_timeout().
Yuck.
I think that the IPI idea would be far better, and a much smaller patch.
We can continue using the comp
The complete() should not be used on offlined CPU. Rewrite the
wait-complete mechanism with wait_on_bit_timeout().
The CPU triggering hot unplug (e.g. CPU0) will loop until some bit is
cleared. In each iteration schedule_timeout() is used with initial sleep
time of 1 ms. Later it is increased to 1
46 matches
Mail list logo
