• Yi Li's avatar
    Blackfin: SMP: rewrite IPI handling to avoid memory allocation · 73a40064
    Yi Li authored
    Currently, sending an interprocessor interrupt (IPI) requires building up
    a message dynamically which means memory allocation.  But often times, we
    will want to send an IPI in low level contexts where allocation is not
    possible which may lead to a panic().  So create a per-cpu static array
    for the message queue and use that instead.
    
    Further, while we have two supplemental interrupts, we are currently only
    using one of them.  So use the second one for the most common IPI message
    of all -- smp_send_reschedule().  This avoids ugly contention for locks
    which in turn would require an IPI message ...
    
    In general, this improves SMP performance, and in some cases allows the
    SMP port to work in places it wouldn't before.  Such as the PREEMPT_RT
    state where the slab is protected by a per-cpu spin lock.  If the slab
    kmalloc/kfree were to put the task to sleep, and that task was actually
    the IPI handler, then the system falls down yet again.
    
    After running some various stress tests on the system, the static limit
    of 5 messages seems to work.  On the off chance even this overflows, we
    simply panic(), and we can review that scenario to see if the limit needs
    to be increased a bit more.
    Signed-off-by: default avatarYi Li <yi.li@analog.com>
    Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
    73a40064
smp.h 728 Bytes