linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 3/3] iomap: optimize iomap_is_partially_uptodate for full page range
Date: Fri, 14 Dec 2018 08:10:19 -0600	[thread overview]
Message-ID: <568c811c-bfd5-216e-30a0-c54ebc2989a0@sandeen.net> (raw)
In-Reply-To: <20181214030528.GK6311@dastard>

On 12/13/18 9:05 PM, Dave Chinner wrote:
> On Thu, Dec 13, 2018 at 04:25:29PM -0600, Eric Sandeen wrote:
>> From: Eric Sandeen <sandeen@redhat.com>
>>
>> We only call ->is_partially_uptodate to look for an uptodate range
>> within a not-uptodate page.
>>
>> If the range covers all blocks in the page, there is no point to checking
>> each block individually - if the whole range (i.e. the whole page) were
>> uptodate, the page would be uptodate as well.  Hence in this case, we
>> can return early and skip the loop.
>>
>> This is similar to what is done in block_is_partially_uptodate().
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
>> ---
>>  fs/iomap.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/fs/iomap.c b/fs/iomap.c
>> index ce837d9..7d7d985 100644
>> --- a/fs/iomap.c
>> +++ b/fs/iomap.c
>> @@ -515,6 +515,10 @@ struct iomap_readpage_ctx {
>>  	first = from >> inode->i_blkbits;
>>  	last = (from + len - 1) >> inode->i_blkbits;
>>  
>> +	/* If page wasn't uptodate and range covers all blocks: no partial */
>> +	if (first == 0 && last == (PAGE_SIZE - 1) >> inode->i_blkbits)
>> +		return 0;
>> +
> 
> Even if the range covers the entire page, we still have to check
> that all the individual blocks in the page are up to date or not.
> Hence I think this is wrong....

Didn't PageUptodate(page) answer that question already in the caller?

The caller does:

                        if (PageUptodate(page))
                                goto page_ok;
...
                        if (!mapping->a_ops->is_partially_uptodate(page,
                                                        offset, iter->count))
                                goto page_not_up_to_date_locked;


So if it was found to be uptodate, we never called this op.  If we /were/
called (page was not uptodate) that can only be because at least one block in
the page is not uptodate.  So what's the need for checking them all again?

(unless it's because we're now doing it under the page lock?)

block_is_partially_uptodate does the same thing:

        if (from < blocksize && to > PAGE_SIZE - blocksize)
                return 0;

Still, this also seems like maybe something the caller should do instead.

-Eric

  reply	other threads:[~2018-12-14 14:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13 22:25 [PATCH 0/3] iomap: 1 cleanup, 1 fix, 1 optimization Eric Sandeen
2018-12-13 22:25 ` [PATCH 1/3] iomap: use SECTOR_SIZE instead of 512 in iomap_page Eric Sandeen
2018-12-15 10:51   ` Christoph Hellwig
2018-12-17 23:45     ` Eric Sandeen
2018-12-18 18:06       ` Christoph Hellwig
2018-12-18 18:19         ` Darrick J. Wong
2018-12-18 18:20           ` Eric Sandeen
2018-12-13 22:25 ` [PATCH 2/3] iomap: don't search past page end in iomap_is_partially_uptodate Eric Sandeen
2018-12-14  2:57   ` Dave Chinner
2018-12-14 13:48     ` Eric Sandeen
2018-12-14 22:14   ` [PATCH 2/3 V2] mm: don't search past page end in is_partially_uptodate Eric Sandeen
2018-12-15 10:49     ` Christoph Hellwig
2018-12-13 22:25 ` [PATCH 3/3] iomap: optimize iomap_is_partially_uptodate for full page range Eric Sandeen
2018-12-14  3:05   ` Dave Chinner
2018-12-14 14:10     ` Eric Sandeen [this message]
2018-12-17 23:21       ` Dave Chinner
2018-12-13 22:27 ` [PATCH 0/3] iomap: 1 cleanup, 1 fix, 1 optimization Eric Sandeen

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=568c811c-bfd5-216e-30a0-c54ebc2989a0@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@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).