Raw i/o usage wrecks block device performance??
Hi, Here's a very strange (and repeatable) result. Affects 2.2.x + raw device patches (i.e. RH7.0). Also had a similar effect on 2.4.0test9! The problem is best described with a little sequence. After using raw i/o facilities, streamed block device reads from the same underlying device exhibit much poorer performance than before the raw i/o. Example [root@localhost /root]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 3.81 seconds = 16.80 MB/sec [root@localhost /root]# time dd if=/dev/raw/raw1 of=/dev/null bs=1024k count=64 64+0 records in 64+0 records out real0m2.990s user0m0.010s sys 0m0.450s [root@localhost /root]# hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 64 MB in 6.12 seconds = 10.46 MB/sec The read figures before and after the raw i/o are repeatable with only little jitter. Raw device reads are consistent and not affected by this phenomena. Anyone know what's going on? Looks like a bug or inefficiency somewhere in the kernel. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raw i/o usage wrecks block device performance??
Hi, On Wed, Oct 11, 2000 at 09:28:57PM +0100, Chris Evans wrote: > > The problem is best described with a little sequence. After using raw i/o > facilities, streamed block device reads from the same underlying device > exhibit much poorer performance than before the raw i/o. > > Anyone know what's going on? Looks like a bug or inefficiency somewhere in > the kernel. It looks as if "hdparm -t" is getting hurt by the fact that raw IO sets the underlying device's blocksize to 512 bytes (Unix APIs require that raw character devices allow arbitrary sector-aligned IO). I'll trace it once I get back from ALS to see if there's anything obviously funny going on. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
