On Thu, 2001-09-20 at 13:37, Roger Larsson wrote:
> > Worst 20 latency times of 4261 measured in this period.
> > usec cause mask start line/file address end line/file
> > 4617 reacqBKL 0 1375/sched.c c0114d94 1381/sched.c
>
> This is fantastic! It REALLY is!
> When we started with the low latency work we aimed at 10 ms.
> (in all situations, not only when running dbench... but still)
Yes it really is, especially noting that that 4.6ms lock is the
_longest_ held lock on the system.
I am seeing 90% of the reported locks under 15ms, and this means that
almost all the locks on the system are even less.
However, I am also seeing some stray 20-50ms and even 60-70ms latencies
and those bother me. I am looking into another solution, perhaps
conditional scheduling for now.
> Lets see - no swap used? - not swapped out
> But with priority altered - it is unlikely that it would not be scheduled
> in for such a long time.
>
> Might it be that the disk is busy to handle dbench requests. 16 threads ->
> 16 read and several (async) write requests at different disk locations in
> queue - make it 20. Seek time 10 ms => queue length 200 ms... probable???
> Do you have more than one disk? Try to run dbench on one and the player from
> the other.
Good idea.
-- Robert M. Love rml at ufl.edu rml at tech9.net- 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/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:40 EST