On 11/26/2013 10:41 AM, Benjamin Herrenschmidt wrote:
>> Right, but the issue per-se is not clobbering of msg holder, but from POV of
>> > receiver, seeming coalescing of 2 set_bit writes to msg holder.
> That's fine. There's no expectation that N ipi_send_msg turn into N
> messages received... it
On Tue, 2013-11-26 at 10:17 +0530, Vineet Gupta wrote:
> On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
> >
> >> Before reading ur email I was coding something like below:
> >>
> >> void arch_send_ipi(int cpu, int type)
> >> {
> >>
On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
>
>> Before reading ur email I was coding something like below:
>>
>> void arch_send_ipi(int cpu, int type)
>> {
>> u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
>>
>> while
On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
> Before reading ur email I was coding something like below:
>
> void arch_send_ipi(int cpu, int type)
> {
> u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
>
> while (cmpxchg(pending_ptr, 0, 1 << type) != 0)
> cpu_relax();
>
>
On Mon, Nov 25, 2013 at 01:35:38PM +, Vineet Gupta wrote:
> On 11/25/2013 05:57 PM, Peter Zijlstra wrote:
> > So sure, then someone can again assert the interrupt, but given we just
> > established a protocol for raising the thing; namely something like
> > this:
> >
> > void
On 11/25/2013 05:57 PM, Peter Zijlstra wrote:
> On Mon, Nov 25, 2013 at 05:00:18PM +0530, Vineet Gupta wrote:
>> While we are at it, I wanted to confirm another potential race
>> (ARC/blackfin..)
>> The IPI handler clears the interrupt before atomically-read-n-clear the msg
>> word.
>>
>> do_IPI
On Mon, Nov 25, 2013 at 05:00:18PM +0530, Vineet Gupta wrote:
> While we are at it, I wanted to confirm another potential race
> (ARC/blackfin..)
> The IPI handler clears the interrupt before atomically-read-n-clear the msg
> word.
>
> do_IPI
>plat_smp_ops.ipi_clear(irq);
>while
On 11/25/2013 04:30 PM, Peter Zijlstra wrote:
> On Mon, Nov 25, 2013 at 04:22:18PM +0530, Vineet Gupta wrote:
>> Hi,
>>
>> I've been looking into cleaning up bitrot in ARC SMP support. Unlike some
>> other
>> arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say
>> cross
>>
On Mon, Nov 25, 2013 at 04:22:18PM +0530, Vineet Gupta wrote:
> Hi,
>
> I've been looking into cleaning up bitrot in ARC SMP support. Unlike some
> other
> arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say cross
> function call) corresponding to IPI needs to be encoded in
Hi,
I've been looking into cleaning up bitrot in ARC SMP support. Unlike some other
arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say cross
function call) corresponding to IPI needs to be encoded in a per-cpu word (1 bit
per msg type) before kicking the IPI.
The current
Hi,
I've been looking into cleaning up bitrot in ARC SMP support. Unlike some other
arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say cross
function call) corresponding to IPI needs to be encoded in a per-cpu word (1 bit
per msg type) before kicking the IPI.
The current
On Mon, Nov 25, 2013 at 04:22:18PM +0530, Vineet Gupta wrote:
Hi,
I've been looking into cleaning up bitrot in ARC SMP support. Unlike some
other
arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say cross
function call) corresponding to IPI needs to be encoded in a
On 11/25/2013 04:30 PM, Peter Zijlstra wrote:
On Mon, Nov 25, 2013 at 04:22:18PM +0530, Vineet Gupta wrote:
Hi,
I've been looking into cleaning up bitrot in ARC SMP support. Unlike some
other
arches/platforms, we don't have per-msg-type IRQ, so the actual msg (say
cross
function call)
On Mon, Nov 25, 2013 at 05:00:18PM +0530, Vineet Gupta wrote:
While we are at it, I wanted to confirm another potential race
(ARC/blackfin..)
The IPI handler clears the interrupt before atomically-read-n-clear the msg
word.
do_IPI
plat_smp_ops.ipi_clear(irq);
while ((pending =
On 11/25/2013 05:57 PM, Peter Zijlstra wrote:
On Mon, Nov 25, 2013 at 05:00:18PM +0530, Vineet Gupta wrote:
While we are at it, I wanted to confirm another potential race
(ARC/blackfin..)
The IPI handler clears the interrupt before atomically-read-n-clear the msg
word.
do_IPI
On Mon, Nov 25, 2013 at 01:35:38PM +, Vineet Gupta wrote:
On 11/25/2013 05:57 PM, Peter Zijlstra wrote:
So sure, then someone can again assert the interrupt, but given we just
established a protocol for raising the thing; namely something like
this:
void arch_send_ipi(int cpu, int
On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
Before reading ur email I was coding something like below:
void arch_send_ipi(int cpu, int type)
{
u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
while (cmpxchg(pending_ptr, 0, 1 type) != 0)
cpu_relax();
On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
Before reading ur email I was coding something like below:
void arch_send_ipi(int cpu, int type)
{
u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu);
while (cmpxchg(pending_ptr,
On Tue, 2013-11-26 at 10:17 +0530, Vineet Gupta wrote:
On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote:
On Mon, 2013-11-25 at 13:35 +, Vineet Gupta wrote:
Before reading ur email I was coding something like below:
void arch_send_ipi(int cpu, int type)
{
u32 *pending_ptr
On 11/26/2013 10:41 AM, Benjamin Herrenschmidt wrote:
Right, but the issue per-se is not clobbering of msg holder, but from POV of
receiver, seeming coalescing of 2 set_bit writes to msg holder.
That's fine. There's no expectation that N ipi_send_msg turn into N
messages received... it turns
20 matches
Mail list logo
