![]() | |||||||||||||
Messages in this thread |
* Ingo Molnar <mingo@elte.hu> wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > > > the additional +1 msec comes from the fact that 1-deep lock/unlock of > > lock1 is an allowed operation too - 2 msec would be the limit if the > > only sequence is the 2-deep one. > > > > so i think the numbers, at least in the 2-deep case, are quite close > > to the theoretical boundary. > > in the generic case i think the theoretical boundary should be something > like: > > sum(i=1...n)(i) == (n+1) * n / 2 > > n=1 limit=1 > n=2 limit=3 > n=3 limit=6 > n=4 limit=10 > > this is quite close to what you have measured for n=1,2,3, and i think > it's becoming exponentially harder to trigger the worst-case with higher > N, so the measured results will likely be lower than that. also, you might want to try the simpler N-deep-locking-only variant, where the maximum latency should be 'n'. This likely needs some changes to the blocker.c code though - i.e. set 'max' always to lock_depth. Ingo - 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: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||||