Re: [PATCH v4 1/1] powerpc: enable dynamic preemption

Hi Paul,

>> I tried moving to PACA plus splitting 64 bit into need_resched and preempt
>> count. But it doesn;t move the needle. But it maybe worth pursuing,
>> since it could help preemption modes. It needs more work and needs numbers
>> across benchmark.
>>
>>> Thanks for trying. Paul questioned whether barriers are actually
>>> needed for preempt_count, or whether software interrupt disabling
>>> would suffice (his words: "I can see why the preempt_count()
>>> operations need to be interrupt-safe, but I don't see why you would
>>> need barriers"). Any thoughts on whether that's feasible for
>>> powerpc?
>>
>> Barrier are likely not the concern as it is mostly nop.
>> Also, soft disabling interrupts needs to arch specific hooks to setup
>> before preempt_disable and replay interrupts after preempt_enable.
>> I don't think it would benefit since interrupt disabling during this likely
>> shouldn't happen. Maybe I don't understand how that could work.
> 
> For some reason, I remembered powerpc software-disabling interrupts,
> but when I go look now, there is no such thing.  Maybe powerpc used to
> but no longer does.  Or maybe I am just hallucinating.  ;-)
> 
> 							Thanx, Paul

It is there still,

static inline unsigned long arch_local_irq_save(void)
{
         return irq_soft_mask_or_return(IRQS_DISABLED);
}
Sets the softmask bit, and any interrupt that arrives,
gets added to a list and that will be replayed in arch_local_irq_restore.

That will protect against the race of irq vs preempt count in
__preempt_count_dec_and_test. In the PACA based PoC i have i tried to use it,
but it doesn't make a difference, since this particular test accounts mainly
preempt count overhead itself, which cannot be escaped in dynamic preemption.

So, I think this is the tax we got to live with for dynamic preemption on RISC archs.
But good thing is, its effect is limited to a very few microbenchmarks.