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.
