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

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