![]() | |||||||||||||
Messages in this thread
|
On Fri, 29 Sep 2006 23:58:28 -0000 Thomas Gleixner <tglx@linutronix.de> wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > For CONFIG_NO_HZ we need to calculate the next timer wheel event based > to a given jiffie value. Extend the existing code to allow the extra now > argument. Provide a compability function for the existing implementations > to call the function with now = jiffies. > This also solves the racyness of the original code vs. jiffies changing > during the iteration. > I think this change has the potential to significantly increase the hold time of tvec_base_t.lock. Quite a lot of code has been moved inside that lock, but most worrisome is that hrtimer_get_next_event() is also now inside it. What workloads is this change likely to impact, and how can we set about verifying that we aren't introducing a problem? Was that (unchangelogged) locking change even needed? If so, why? - 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/ | ||||||||||||
| Last update: 2006-09-30 10:41 [from the cache] ©2003-2008 | |||||||||||||