core kernel fixes
Linus,
Please pull the latest core-fixes-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core-fixes-for-linus
Thanks,
Ingo
------------------>
Paul E. McKenney (2):
rcu: demote SRCU_SYNCHRONIZE_DELAY from kernel-parameter status
rcu: avoid pointless blocked-task warnings
Steven Rostedt (1):
rtmutex: Fix comment about why new_owner can be NULL in wake_futex_pi()
init/Kconfig | 15 --------------- kernel/futex.c | 7 +++---- kernel/rcutiny.c | 3 ++- kernel/srcu.c | 15 +++++++++++++-- 4 files changed, 18 insertions(+), 22 deletions(-)
init/Kconfig +0 -15
@@ -497,21 +497,6 @@ config RCU_BOOST_DELAY Accept the default if unsure. -config SRCU_SYNCHRONIZE_DELAY - int "Microseconds to delay before waiting for readers" - range 0 20 - default 10 - help - This option controls how long SRCU delays before entering its - loop waiting on SRCU readers. The purpose of this loop is - to avoid the unconditional context-switch penalty that would - otherwise be incurred if there was an active SRCU reader, - in a manner similar to adaptive locking schemes. This should - be set to be a bit longer than the common-case SRCU read-side - critical-section overhead. - - Accept the default if unsure. - endmenu # "RCU Subsystem" config IKCONFIG
kernel/futex.c +3 -4
@@ -791,10 +791,9 @@ static int wake_futex_pi(u32 __user *uaddr, u32 uval, struct futex_q *this) new_owner =rt_mutex_next_owner (&pi_state->pi_mutex);/* -* This happens when we have stolen the lock and the original -* pending owner did not enqueue itself back on the rt_mutex. -* Thats not a tragedy. We know that way, that a lock waiter -* is on the fly. We make the futex_q waiter the pending owner. +* It is possible that the next waiter (the one that brought +* this owner to the kernel) timed out and is no longer +* waiting on the lock. */ if (!new_owner) new_owner = this->task;
kernel/rcutiny.c +2 -1
@@ -189,7 +189,8 @@ static int rcu_kthread(void *arg)unsigned long flags;for (;;) { -wait_event (rcu_kthread_wq, have_rcu_kthread_work !=0 ); +wait_event_interruptible (rcu_kthread_wq, + have_rcu_kthread_work !=0 ); morework =rcu_boost ();local_irq_save (flags); work = have_rcu_kthread_work;
kernel/srcu.c +13 -2
@@ -156,6 +156,16 @@ void __srcu_read_unlock(struct srcu_struct *sp, int idx)EXPORT_SYMBOL_GPL (__srcu_read_unlock);/* +* We use an adaptive strategy for synchronize_srcu() and especially for +* synchronize_srcu_expedited(). We spin for a fixed time period +* (defined below) to allow SRCU readers to exit their read-side critical +* sections. If there are still some readers after 10 microseconds, +* we repeatedly block for 1-millisecond time periods. This approach +* has done well in testing, so there is no need for a config parameter. +*/ +#define SYNCHRONIZE_SRCU_READER_DELAY 10 + +/* * Helper function for synchronize_srcu() and synchronize_srcu_expedited(). */ static void __synchronize_srcu (struct srcu_struct *sp,void (*sync_func)(void ))
@@ -207,11 +217,12 @@ static void __synchronize_srcu(struct srcu_struct *sp, void (*sync_func)(void))* will have finished executing. We initially give readers * an arbitrarily chosen 10 microseconds to get out of their * SRCU read-side critical sections, then loop waiting 1/HZ -* seconds per iteration. +* seconds per iteration. The 10-microsecond value has done +* very well in testing. */ if (srcu_readers_active_idx (sp, idx)) -udelay (CONFIG_SRCU_SYNCHRONIZE_DELAY ); +udelay (SYNCHRONIZE_SRCU_READER_DELAY );while (srcu_readers_active_idx (sp, idx))schedule_timeout_interruptible (1 );