All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@fb.com>
To: Dave Chinner <david@fromorbit.com>
Cc: <linux-block@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<jack@suse.cz>
Subject: Re: [PATCH 0/3] writeback: minor tweaks
Date: Tue, 12 Apr 2016 19:49:45 -0600	[thread overview]
Message-ID: <570DA5B9.3000507@fb.com> (raw)
In-Reply-To: <20160413000857.GB10643@dastard>

On 04/12/2016 06:08 PM, Dave Chinner wrote:
> On Tue, Apr 12, 2016 at 12:43:50PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Three top level patches out of the writeback throttling patchset, that
>> I think should make it into mainline. No functional changes in the
>> first two patches, and the last patch just bumps reclaim/sync
>> writeback to use WRITE_SYNC as a hint to the block layer.
>
> Whatever happened to adding a new flag to indicate that write
> requests can be throttled, rather than overloading WRITE_SYNC with
> yet another (conflicting) meaning?

WRITE_SYNC means someone will be waiting for it. This just extends it to 
cover more instances where that is the case (reclaim, for_sync).

For background writes, we'll want to split WRITE into WRITE and 
WRITE_BACKGROUND.

Alternatively, I can stop extending WRITE_SYNC for the other parts, and 
only do the background part. But I think those parts makes sense.

> I've already pointed out the problems associated with tagging async,
> bulk writes as synchronous writes so that a lower layer can avoid

I think that's our miscommunication. It's not my intent to tag async 
writes as sync. If we're doing reclaim, presumable someone is waiting 
for those pages to be cleaned. Hence sync. Ditto for for_sync.

> throttling them. Please add a new flag for communicating whether
> writes can be throttled to the block layer instead of reusing
> WRITE_SYNC.

If someone is waiting for them, they won't be throttled as hard 
(WRITE_SYNC, WRITE_ODIRECT, etc). If someone is not waiting for them 
(WRITE), then we can throttle a bit more.

That's my intent. We can add WRITE_BACKGROUND, but then we have one more 
write type. Why not just leave WRITE as the background type of write?

-- 
Jens Axboe


  reply	other threads:[~2016-04-13  1:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 18:43 [PATCH 0/3] writeback: minor tweaks Jens Axboe
2016-04-12 18:43 ` [PATCH 1/3] writeback: propagate the various reasons for writeback Jens Axboe
2016-04-13  9:48   ` Jan Kara
2016-04-14 15:43     ` Jens Axboe
2016-04-17 12:01       ` Jan Kara
2016-04-12 18:43 ` [PATCH 2/3] writeback: add wbc_to_write() Jens Axboe
2016-04-13  9:50   ` Jan Kara
2016-04-14 15:41     ` Jens Axboe
2016-04-12 18:43 ` [PATCH 3/3] writeback: use WRITE_SYNC for reclaim or sync writeback Jens Axboe
2016-04-13  0:08 ` [PATCH 0/3] writeback: minor tweaks Dave Chinner
2016-04-13  1:49   ` Jens Axboe [this message]
2016-04-13  6:09     ` Dave Chinner
2016-04-13 10:07     ` Jan Kara
2016-04-14 15:41       ` Jens Axboe

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=570DA5B9.3000507@fb.com \
    --to=axboe@fb.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.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 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.