Messages in this thread | | | Date | Thu, 22 Mar 2012 09:38:19 +0200 | Subject | Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs it | From | Gilad Ben-Yossef <> |
| |
On Wed, Mar 21, 2012 at 4:54 PM, Christoph Lameter <cl@linux.com> wrote: > On Wed, 21 Mar 2012, Frederic Weisbecker wrote: > >> If RCU is waiting for the current CPU to complete a grace >> period, don't turn off the tick. Unlike dynctik-idle, we >> are not necessarily going to enter into rcu extended quiescent >> state, so we may need to keep the tick to note current CPU's >> quiescent states. > > Is there any way for userspace to know that the tick is not off yet due to > this? It would make sense for us to have busy loop in user space that > waits until the OS has completed all processing if that avoids future > latencies for the application. >
I previously suggested having the user register to receive a signal when the tick is turned off. Since the tick is always turned off the user task is the current task by design, *I think* you can simply mark the signal pending when you turn the tick off.
The user would register a signal handler to set a flag when it is called and then busy loop waiting for a flag to clear.
Checking this approach is on my todo list, but alas I had no progress with it yet :-)
Gilad
-- Gilad Ben-Yossef Chief Coffee Drinker gilad@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com
"If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |