Messages in this thread | | | Subject | Re: [PATCH [RT] 08/14] add a loop counter based timeout mechanism | From | Sven-Thorsten Dietrich <> | Date | Thu, 21 Feb 2008 09:06:15 -0800 |
| |
On Thu, 2008-02-21 at 17:41 +0100, Andi Kleen wrote: > > +config RTLOCK_DELAY > > + int "Default delay (in loops) for adaptive rtlocks" > > + range 0 1000000000 > > + depends on ADAPTIVE_RTLOCK > > I must say I'm not a big fan of putting such subtle configurable numbers > into Kconfig. Compilation is usually the wrong place to configure > such a thing. Just having it as a sysctl only should be good enough. > > > + default "10000" > > Perhaps you can expand how you came up with that default number?
We did not want to create a hotspot around time sources for HRT and the scheduler clock, and there really hasn't been enough analyis.
The loop should be calibrated using something similar to loops_per_jiffy, and it should be in nanoseconds.
It needs to be tunable, because it depends a lot on the workload.
High frequency periodic tasks would need a lower setting - but it also relates to the number of waiting tasks and the number of CPUs, so there may be heuristics that tie into lockstat.
For big-SMP systems, it may actually be worth the overhead to track these stats per-lock (for the hot locks), if we can correlate it all to performance.
> It looks suspiciously round and worse the actual spin time depends a lot on the > CPU frequency (so e.g. a 3Ghz CPU will likely behave quite > differently from a 2Ghz CPU) Did you experiment with other spin times? > Should it be scaled with number of CPUs? And at what point is real > time behaviour visibly impacted? >
The code actually runs preemptibly, so even before the timeout expires, the task can pop off the CPU (at which point another state chance cancels the loop)
> Most likely it would be better to switch to something that is more > absolute time, like checking RDTSC every few iteration similar to what > udelay does. That would be at least constant time. >
True - I looked at something generic, similar to what RT's latency tracing uses, allowing for other architectures.
Sven
> -Andi > -- > 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/
| |