summaryrefslogtreecommitdiffstats
path: root/crypto/mcryptd.c
diff options
context:
space:
mode:
authorDavidlohr Bueso <dave@stgolabs.net>2016-10-11 13:54:56 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2016-10-11 15:06:33 -0700
commite3658538bf3727383b4e563fbab83c04d615508a (patch)
tree55b66ab4eebb097928d8790b0be6add58ba64656 /crypto/mcryptd.c
parentee51636ca54f9d4d01ae49b1740742e9db54d868 (diff)
downloadlinux-e3658538bf3727383b4e563fbab83c04d615508a.tar.gz
linux-e3658538bf3727383b4e563fbab83c04d615508a.tar.bz2
linux-e3658538bf3727383b4e563fbab83c04d615508a.zip
ipc/msg: batch queue sender wakeups
Currently the use of wake_qs in sysv msg queues are only for the receiver tasks that are blocked on the queue. But blocked sender tasks (due to queue size constraints) still are awoken with the ipc object lock held, which can be a problem particularly for small sized queues and far from gracious for -rt (just like it was for the receiver side). The paths that actually wakeup a sender are obviously related to when we are either getting rid of the queue or after (some) space is freed-up after a receiver takes the msg (msgrcv). Furthermore, with the exception of msgrcv, we can always piggy-back on expunge_all that has its own tasks lined-up for waking. Finally, upon unlinking the message, it should be no problem delaying the wakeups a bit until after we've released the lock. Link: http://lkml.kernel.org/r/1469748819-19484-3-git-send-email-dave@stgolabs.net Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'crypto/mcryptd.c')
0 files changed, 0 insertions, 0 deletions