Re: [git patches] IDE update

From: Jens Axboe (axboe_at_suse.de)
Date: 07/08/05

  • Next message: Rui Nuno Capela: "realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]"
    Date:	Fri, 8 Jul 2005 10:48:21 +0200
    To: Linus Torvalds <torvalds@osdl.org>
    
    
    

    On Tue, Jul 05 2005, Linus Torvalds wrote:
    > So my gut feel is that the reason hdparm and dd from the raw partition
    > gives different performance is not so much the driver, but probably that
    > we've tweaked read-ahead for file access or something like that. Maybe
    > the maximum fs-level read-ahead changed?

    I don't think this is the case. I butchered a test system here and
    successfully got it running a P2 at 375MHz (don't ask, messing with
    multipliers and FSB with slot-1 cpu's has been a while) and 2.6 was
    still faster.

    But! I used hdparm -t solely, 2.6 was always ~5% faster than 2.4. But
    using -Tt slowed down the hd speed by about 30%. So it looks like some
    scheduler interaction, perhaps the memory timing loops gets it marked as
    batch or something?

    hdparm really does nothing special - it reads the disk in 2MiB chunks,
    calling getitimer() in between to stop at 3 seconds.

    bart:~ # uname -a
    Linux bart 2.6.13-rc2 #2 SMP Fri Jul 8 09:51:39 CEST 2005 i686 i686 i386
    GNU/Linux

    bart:~ # hdparm -Tt /dev/hdc

    /dev/hdc:
     Timing buffer-cache reads: 380 MB in 2.00 seconds = 190.00 MB/sec
     Timing buffered disk reads: 64 MB in 3.06 seconds = 20.92 MB/sec
    bart:~ # hdparm -t /dev/hdc

    /dev/hdc:
     Timing buffered disk reads: 88 MB in 3.05 seconds = 28.85 MB/sec

    I'm attaching a silly test case that demonstrates the problem by reading
    512MiB from a given disk.

    bart:~ # ./read_disk /dev/hdc
    Disk Throughput: 29 MiB/sec
    bart:~ # ./read_disk /dev/hdc 1
    Mem Throughput: 102 MiB/sec
    Mem Throughput: 101 MiB/sec
    Disk Throughput: 21 MiB/sec

    Passing an extra argument to the program, makes it do the same priming
    loop as hdparm. That part runs at 100% system time, just copying data to
    user space and issuing an lseek for each read. Again, if I run this on
    my workstation (dual core em64t), it doesn't show the problem.

    hdparm strace -tt timings also attached.

    -- 
    Jens Axboe
    
    
    
    

    -
    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/





  • Next message: Rui Nuno Capela: "realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]"