Messages in this thread |  | | | Date | Wed, 28 Mar 2012 13:53:07 +0200 | | From | Frederic Weisbecker <> | | Subject | Re: [PATCH 11/32] nohz/cpuset: Don't turn off the tick if rcu needs it |
| |
On Tue, Mar 27, 2012 at 11:13:39AM -0500, Christoph Lameter wrote: > On Tue, 27 Mar 2012, Frederic Weisbecker wrote: > > > > 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. > > > > What is the usecase you have in mind? Is it for realtime purpose? > > Please do not use "realtime" since I am not sure what you mean by that. > Its for a low latency applications that cannot use "realtime" because that > implies high latencies. > > > The "tick stopped" is a volatile and relative state. > > The use case is an application that cannot tolerate the latencies > introduced by timer tick processing. It will only start running when the > system is in a sufficiently quiet state. > > > Relative because if a timer list is enqueued to fire 1 second later, > > the tick will be stopped until that happens. How do we consider this (common) > > case? > > > > Also as Chris noted it is volatile because the tick can be restarted anytime > > for random reasons: the CPU receives an IPI which makes it restart the > > periodic tick. > > Ok some sort of notification would be good for that case. If a timer tick > happens and that was unavoidable then it would be good to log the reason > why this occured so that the system can be configured in such a way that > these interruptions are minimized.
tracing is probably the right place to log these things. But that's about debugging. This won't be a notification on top of which your app could recover.
|  |