Re: write is faster whan seek?

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Jun 11 2008, Dmitri Monakhov wrote:
> Jens Axboe <jens.axboe@oracle.com> writes:
> 
> > On Wed, Jun 11 2008, Dmitri Monakhov wrote:
> >> Jens Axboe <jens.axboe@oracle.com> writes:
> >> 
> >> > On Wed, Jun 11 2008, Dmitri Monakhov wrote:
> >> >> I've found what any non continious sequence violation  result in significant
> >> >> pefrormance drawback. I've two types of requests:
> >> >> 1)Ideally sequential  writes:
> >> >>    for(i=0;i<num;i++) {
> >> >>        write(fd, chunk, page_size*32);
> >> >>    } 
> >> >>    fsync(fd);
> >> >> 
> >> >> 2) Sequential writes with dgap for each 32'th page
> >> >>    for(i=0;i<num;i++) {
> >> >>        write(fd, chunk, page_size*31);
> >> >>        lseek(fd, page_size, SEEK_CUR);
> >> >>    }
> >> >>    fsync(fd);
> >> >> 
> >> >> I've found what second IO pattern is about twice times slower whan the
> >> >> first one regardless to ioscheduler or HW disk. It is not clear to me
> >> >> why this happen. Is it linux speciffic or general hardware behaviour
> >> >> speciffic.  I've naively expected what disk hardware cat merge several
> >> >> 31-paged requests in to continious one by filling holes by some sort
> >> >> of dummy activity.
> >> >
> >> > Performance should be about the same. The first is always going to be a
> >> > little faster, on some hardware probably quite a bit. Are you using
> >> > write back caching on the drive? I ran a quick test here, and the second
> >> > test is about ~5% slower on this drive.
> >> Hmmm... it is definitly not happen in may case.  
> >> I've tested following sata drive w and w/o write cache
> >> AHCI
> >> ata7.00: ATA-7: ST3250410AS, 3.AAC, max UDMA/133
> >> ata7.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> >> In all cases it is about two times slower.
> >> 
> >> # time   /tmp/wr_test /dev/sda3 32 0 800
> >> real    0m1.183s
> >> user    0m0.002s
> >> sys     0m0.079s
> >> 
> >> # time   /tmp/wr_test /dev/sda3 31 1 800
> >> real    0m3.240s
> >> user    0m0.000s
> >> sys     0m0.078s
> >
> > Ahh, direct to device. Try making a 4kb fs on sda3, mount it, umount
> > it, then rerun the test.
> Noup.. no changes at all.
> # cat /sys/block/sda/queue/scheduler
> [noop] anticipatory deadline cfq
> # blockdev --getbsz  /dev/sda
> 4096
> # hdparm -W 0 /dev/sda
> 
> /dev/sda:
>  setting drive write-caching to 0 (off)
> 
> # time ./wr_test /dev/sda  32 0 800
> real    0m1.185s
> user    0m0.000s
> sys     0m0.106s
> 
> # time ./wr_test /dev/sda  31 1 800
> real    0m3.391s
> user    0m0.002s
> sys     0m0.112s
> 
> 
> I'll try to play with request queue parameters

Try finding out if the issued IO pattern is OK first, you should
understand the problem before you attempt to fix it. Run blktrace on
/dev/sda when you do the two tests and compare the blkparse output!

-- 
Jens Axboe