From: Jens Axboe <jens.axboe@oracle.com>
To: Dmitri Monakhov <dmonakhov@openvz.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: write is faster whan seek?
Date: Wed, 11 Jun 2008 10:26:04 +0200 [thread overview]
Message-ID: <20080611082602.GQ20851@kernel.dk> (raw)
In-Reply-To: <m3k5gwz8zm.fsf@dmon-lap.sw.ru>
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.
--
Jens Axboe
next prev parent reply other threads:[~2008-06-11 8:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 7:20 write is faster whan seek? Dmitri Monakhov
2008-06-11 7:48 ` Jens Axboe
2008-06-11 8:11 ` Dmitri Monakhov
2008-06-11 8:26 ` Jens Axboe [this message]
2008-06-11 9:28 ` Dmitri Monakhov
2008-06-11 9:38 ` Jens Axboe
2008-06-11 11:38 ` Alan D. Brunelle
2008-06-11 11:49 ` Jens Axboe
2008-06-11 11:52 ` Alan D. Brunelle
2008-06-11 11:55 ` Jens Axboe
2008-06-16 12:14 ` Dmitri Monakhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080611082602.GQ20851@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=dmonakhov@openvz.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).