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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
