[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: My vote against eepro* removal
    > From: John Ronciak
    > During the watchdog the e100 driver reads all of the status registers
    > from the actual hardware. There are 26 (worst case) register reads.
    > There is also a spin lock for another check in the watchdog. It would
    > still surprise me that all of this would take 500 usec. If you are
    > seeing this delay, you can comment out the scheduling of the watchdog
    > to see if this goes away. We'll need to narrow down exactly what in
    > the watchdog is causing the delay

    Retested it.

    Software:, no additional patches, configured for full preemption.

    500 MHz Pentium 3
    According to lspci: 82443+82371 Chipset (440 BX + PIIX4)
    According to lspci: 82559ER (09) e100
    100 Mbit full duplex

    Measurement software:
    * I start the rtc at 8192 Hz.
    * I read from /dev/rtc in a usermode realtime process.
    * After each read, I read the tsc and calculate the interval.
    * It should be 122 us most of the time, and indeed it is.
    At rtprio 2-99, practically all measurements are < 160-175 us
    on an otherwise idle machine (160 for 99, 175 for 2).
    At rtprio 1, there are some intervals of up to 300 us on an
    idle machine.
    * The program records the intervals in internal arrays and prints
    them at the end, it doesn't perform any I/O while it is running.

    Basically, my software measures how long it takes for a realtime
    process at prio n to get executed after it became ready:
    The actual interval minus 122 is the time the process was waiting
    for the CPU (didn't get scheduled).
    This means that there was continuous CPU activity for at least
    that long, either at a higher or the same rt prio, on in
    non-thread kernel code.
    (the rtc threaded interrupt handler is running above all others)

    Effect of the e100 driver:
    * There is no measurable effect when my test program is running
    at prio 2 - 99.
    * For prio 1, I get an interval of 500-650 us every 2 seconds,
    which indicates a scheduling latency of 380-530 us.
    Hence, some piece of code is running for ~500 us at rt prio 1.

    Analysis of e100:
    * If I comment out the whole body of e100_watchdog except for the
    timer re-registration, the delays are gone (so it is really the
    body of e100_watchdog). However, this makes eth0 non-functional.
    * Commenting out parts of it, I found out that most of the time
    goes into its first half: The code from mii_ethtool_gset to
    mii_check_link (including) makes the big difference, as far as
    I can tell especially mii_ethtool_gset.

    Effect of desktop preemption:
    With desktop preemption insted of full preemption, the 400-500 us
    scheduling delay hits at any rt priority, even at 99, i.e. the
    CPU is occupied by non-thread kernel code.
    Again, commenting out e100_watchdog brings the delays back to
    well below 400 us.

    Latency traces:
    The latency tracer does not record this scheduling latency.
    My max. traces are around 35 us with full preemption and
    around 70 us with desktop preemption, and are not related to e100.

    Klaus Kusche (Software Development - Control Systems)
    KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
    Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
    E-Mail: WWW:
    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: 2006-01-20 10:40    [W:0.026 / U:0.100 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site