[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Preemption Latency Measurement Tool
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
rml at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.215 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site