Messages in this thread | | | Date | Fri, 27 Aug 2010 11:50:13 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH 00/11] sched: CFS low-latency features |
| |
* Thomas Gleixner (tglx@linutronix.de) wrote: > On Thu, 26 Aug 2010, Mathieu Desnoyers wrote: [...] > > Hrm, thinking about it a little more, one of the "plus" sides of these > > SIGEV_THREAD timers is that a single timer can fork threads that will run on > > many cores on a multi-core system. If we go for preallocation of a single > > thread, we lose that. Maybe we could think of a way to preallocate a thread pool > > instead ? > > Why should a single timer fork many threads? Just because a previous > thread did not complete before the timer fires again? That's > braindamage as all threads call the same function which then needs to > be serialized anyway. We really do not need a function which creates > tons of threads which get all stuck on the same resource.
It could make sense if the workload is mostly CPU-bound and there is only a very short critical section shared between the threads. But I agree that in many cases this will generate an utter contention mess.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |