All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: trying to understand READ_META, READ_SYNC, WRITE_SYNC & co
Date: Mon, 21 Jun 2010 21:16:33 +0200	[thread overview]
Message-ID: <4C1FBA91.3040601@kernel.dk> (raw)
In-Reply-To: <20100621191410.GA24213@lst.de>

On 21/06/10 21.14, Christoph Hellwig wrote:
> On Mon, Jun 21, 2010 at 08:56:55PM +0200, Jens Axboe wrote:
>> FWIW, Windows marks meta data writes and they go out with FUA set
>> on SATA disks. And SATA firmware prioritizes FUA writes, it's essentially
>> a priority bit as well as a platter access bit. So at least we have some
>> one else using a meta data boost. I agree that it would be a lot more
>> trivial to add the annotations if they didn't have scheduler impact
>> as well, but I still think it's a sane thing.
> 
> And we still disable the FUA bit in libata unless people set a
> non-standard module option..

Yes, but that's a separate thing. The point is that boosting meta data
IO is done by others as well. That we don't fully do the same on the
hw side is a different story. That doesn't mean that the io scheduler
boost isn't useful.

>>>> Reads are sync by nature in the block layer, so they don't get that
>>>> special annotation.
>>>
>>> Well, we do give them this special annotation in a few places, but we
>>> don't actually use it.
>>
>> For unplugging?
> 
> We use the explicit unplugging, yes - but READ_META also includes
> REQ_SYNC which is not used anywhere.

That does look superfluous.

>>> But that leaves the question why disabling the idling logical for
>>> data integrity ->writepage is fine?  This gets called from ->fsync
>>> or O_SYNC writes and will have the same impact as O_DIRECT writes.
>>
>> We have never enabled idling for those. O_SYNC should get a nice
>> boost too, it just needs to be benchmarked and tested and then
>> there would be no reason not to add it.
> 
> We've only started using any kind of sync tag last year in ->writepage in
> commit a64c8610bd3b753c6aff58f51c04cdf0ae478c18 "block_write_full_page:
> Use synchronous writes for WBC_SYNC_ALL writebacks", switching from
> WRITE_SYNC to WRITE_SYNC_PLUG a bit later in commit
> 6e34eeddf7deec1444bbddab533f03f520d8458c "block_write_full_page: switch
> synchronous writes to use WRITE_SYNC_PLUG"
> 
> Before that we used plain WRITE, which had the normal idling logic.

Plain write does not idle.

-- 
Jens Axboe


  reply	other threads:[~2010-06-21 19:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-21  9:48 trying to understand READ_META, READ_SYNC, WRITE_SYNC & co Christoph Hellwig
2010-06-21 10:04 ` Jens Axboe
2010-06-21 11:04   ` Christoph Hellwig
2010-06-21 18:56     ` Jens Axboe
2010-06-21 19:14       ` Christoph Hellwig
2010-06-21 19:16         ` Jens Axboe [this message]
2010-06-21 19:20           ` Christoph Hellwig
2010-06-21 21:36         ` Vivek Goyal
2010-06-23 10:01           ` Christoph Hellwig
2010-06-24  1:44             ` Vivek Goyal
2010-06-25 11:03               ` Christoph Hellwig
2010-06-26  3:35                 ` Vivek Goyal
2010-06-26 10:05                   ` Christoph Hellwig
2010-06-26 11:20                     ` Jens Axboe
2010-06-26 11:56                       ` Christoph Hellwig
2010-06-27 15:44                   ` Jeff Moyer
2010-06-29  9:06                     ` Corrado Zoccolo
2010-06-29 12:30                       ` Vivek Goyal
2010-06-29 12:30                         ` Vivek Goyal
2010-06-30 15:30                         ` Corrado Zoccolo
2010-06-30 15:30                           ` Corrado Zoccolo
2010-06-26  9:25                 ` Nick Piggin
2010-06-26  9:27                   ` Christoph Hellwig
2010-06-26 10:10                     ` Nick Piggin
2010-06-26 10:16                       ` Christoph Hellwig
2010-06-21 18:52   ` Jeff Moyer
2010-06-21 18:58     ` Jens Axboe
2010-06-21 19:08       ` Jeff Moyer
2010-06-23  9:26       ` Christoph Hellwig
2010-06-21 20:25   ` Vivek Goyal
2010-06-23 10:02     ` Christoph Hellwig

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=4C1FBA91.3040601@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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 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.