[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP412269A37AB67397C52933966D0@phx.gbl>
Date: Fri, 17 Jun 2011 16:35:23 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
CC: linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
dipankar@...ibm.com, akpm@...ux-foundation.org,
josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
patches@...aro.org
Subject: Re: [PATCH rcu/urgent] Banishing kthreads
* Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> This patchset banishes RCU kthreads from non-RCU_BOOST kernel threads.
> The two patches are as follows:
>
> 1. Minimal patch that #ifdefs out the kthread code.
>
> 2. Code-movement patch that puts the code #ifdefed out above
> under existing #ifdefs in kernel/rcutree_plugin.h.
Hi Paul,
I'm wondering about the impact of this change: so I guess that before
the change, it was OK to go on a waitqueue (might_sleep()) within a
call_rcu callback, but since the execution now moves to a softirq
handler in non-RCU_BOOST kernels, it's not allowed anymore. I might be
missing something though: was sleeping within call_rcu handlers already
prohibited ? (never had to sleep in those, so I never had to check if it
was allowed)
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists