All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCHSET v3 0/4] Submit ->readpages() IO as read-ahead
Date: Wed, 20 Jun 2018 18:06:12 -0600	[thread overview]
Message-ID: <23ee9918-a87a-eeac-4c0d-e71d3bd1e6eb@kernel.dk> (raw)
In-Reply-To: <20180620164511.5bda5d9d37123af787b6f5c4@linux-foundation.org>

On 6/20/18 5:45 PM, Andrew Morton wrote:
> On Wed, 20 Jun 2018 17:33:47 -0600 Jens Axboe <axboe@kernel.dk> wrote:
> 
>>> If we are to remove callers' ability to use readpages for non-readahead
>>> purposes we should rename the address_space field.
>>
>> Totally agree, and I'd be happy to do that. So how about we do that? I
>> rename it to ->readahead (or ->readaheadpages()?), and then it's
>> perfectly clear what is going on.
> 
> I'm not sure I have the heart to recommend that.
> 
> akpm3:/usr/src/linux-4.18-rc1> grep -r readpages .|wc -l
> 233
> 
> Really, every damn one will need an edit.  I'd understand if we left it
> at ->readpages and sprinkled some loud comments around the place.

That would be more convenient... Embrace and extend, I'll resend the
series with some comments added that'll hopefully get the point across.

>>>> Besides, this isn't going to be just about tracing. Yes, it'll be
>>>> awesome to actually get the right information from blktrace, since right
>>>> now nobody knows which parts are read-ahead and which ones are explicit
>>>> reads. Might be pretty darn useful to debug read-ahead issues.
>>>>
>>>> The read-ahead information must be reliable, otherwise it's impossible
>>>> to introduce other dependencies on top of that. We're having a lot of
>>>> issues with termination of tasks that are stuck in issuing read-ahead.
>>>> If we can rely on the read-ahead information being there AND being
>>>> correct, then we can terminate reads early. This might not sound like
>>>> huge win, but we're talking tens of minutes for some cases. That's the
>>>> planned functional change behind this, but can't be done before we make
>>>> progress on the topic at hand.
>>>
>>> Changelog material right there.
>>
>> I deliberately didn't want to include that, since it'd muddy the waters
>> on what is a 100% standalone change.
> 
> Omitting the info muddied the waters!

I claim no ill intent!

> Shrug, I give up.  "readpages is really only for readahead" can become
> another kernel wart, I guess.  Anyone who wants that capability in the
> future can sit there looping on ->readpage.

Or do the leg work, which is a rename and adding ->readpages(). As long
as folks don't get too confused, I think we're fine commandeering
->readpages() for read-ahead now.

-- 
Jens Axboe

  reply	other threads:[~2018-06-21  0:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30 14:42 [PATCHSET v3 0/4] Submit ->readpages() IO as read-ahead Jens Axboe
2018-05-30 14:42 ` [PATCH 1/4] mpage: add argument structure for do_mpage_readpage() Jens Axboe
2018-05-30 14:42 ` [PATCH 2/4] mpage: mpage_readpages() should submit IO as read-ahead Jens Axboe
2018-05-30 14:42 ` [PATCH 3/4] btrfs: readpages() " Jens Axboe
2018-05-30 14:42 ` [PATCH 4/4] ext4: " Jens Axboe
2018-06-19 23:56 ` [PATCHSET v3 0/4] Submit ->readpages() " Andrew Morton
2018-06-20 14:07   ` Jens Axboe
2018-06-20 19:58     ` Andrew Morton
2018-06-20 20:15       ` Chris Mason
2018-06-20 22:28       ` Jens Axboe
2018-06-20 23:23         ` Andrew Morton
2018-06-20 23:33           ` Jens Axboe
2018-06-20 23:45             ` Andrew Morton
2018-06-21  0:06               ` Jens Axboe [this message]
2018-06-21 12:21         ` Christoph Hellwig
2018-06-21 13:52           ` 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=23ee9918-a87a-eeac-4c0d-e71d3bd1e6eb@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.