From: Jens Axboe <jens.axboe@oracle.com>
To: Kyungmin Park <kmpark@infradead.org>
Cc: "'Thomas Petazzoni'" <thomas.petazzoni@free-electrons.com>,
"'Linux Filesystem Mailing List'"
<linux-fsdevel@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Question about synchronous write on SSD
Date: Tue, 19 Feb 2008 11:00:34 +0100 [thread overview]
Message-ID: <20080219100034.GV23197@kernel.dk> (raw)
In-Reply-To: <000301c872dd$91461fd0$1fa9580a@swcenter.sec.samsung.co.kr>
On Tue, Feb 19 2008, Kyungmin Park wrote:
> > >
> > > Agree, however see the following sequence.
> > >
> > > __generic_make_request call q->make_request_fn(q, bio);
> > > It was set by blk_init_queue_node with __make_request.
> > > There are two ways in __make_request.
> > > Case 1, get_rq
> > > Case 2, out or merged (otherwise you mean unplug case)
> > >
> > > In case 1, if the BIO_RW_SYNC is set, the request gets the REQ_RW_SYNC
> > > And REQ_RW_SYNC says
> > > "include/linux/blkdev.h":112: __REQ_RW_SYNC, /* request is sync (O_DIRECT) */
> > > It means it acts as O_DIRECT flag. Is it right?
> > > And it also is same as case 2. Unplug the device.
> > > So next time it hasn't chance to merge???
> >
> > But that still doesn't make it sync. I think you are working the wrong
> > way. For ssd we still want merging and plugging also makes sense to some
> > degree, though it probably should be minimized. It'll only cause an
> > initial latency, for busy IO workloads you wont be plugging/unplugging
> > much anyway.
> >
> > In fact your patch makes things WORSE, since the io schedulers will now
> > treat the IO as sync and introduce idling for the disk head. And you
> > definitely don't want that.
>
> Yes, you're right. It's for testing.
> I just want to know the worst or corner case, if all writes are synchronous.
> Of course I can measure the using tiotest "Do write synchronous" option.
> Then you think it's the worse case?
If you want to test when all writes are sync, then either mount with -o
sync, open with O_SYNC or use O_DIRECT writes. You can't force that
behaviour by changing the block layer code. Perhaps you could force
O_SYNC when a file is opened, if you want to experiment with worst case
generally. Not sure that makes a lot of sense, though.
--
Jens Axboe
prev parent reply other threads:[~2008-02-19 10:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 5:48 Question about synchronous write on SSD Kyungmin Park
2008-02-19 8:16 ` Thomas Petazzoni
2008-02-19 9:39 ` Kyungmin Park
2008-02-19 9:39 ` Kyungmin Park
2008-02-19 9:43 ` Jens Axboe
2008-02-19 9:43 ` Jens Axboe
2008-02-19 9:55 ` Kyungmin Park
2008-02-19 10:00 ` Jens Axboe [this message]
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=20080219100034.GV23197@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=kmpark@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.petazzoni@free-electrons.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.