summaryrefslogtreecommitdiff
path: root/arch/blackfin/mach-bf537
diff options
context:
space:
mode:
authorYi Li <yi.li@analog.com>2009-12-17 08:20:32 +0000
committerMike Frysinger <vapier@gentoo.org>2011-01-10 07:18:15 -0500
commit73a400646b8e26615f3ef1a0a4bc0cd0d5bd284c (patch)
tree331002731d5aac594bb99a5a9cc61f5c0933ca69 /arch/blackfin/mach-bf537
parent2c1657c29f810d0ba32cde54cba1e916815493e5 (diff)
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
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: Yi Li <yi.li@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Diffstat (limited to 'arch/blackfin/mach-bf537')
0 files changed, 0 insertions, 0 deletions