From: Matthew Wilcox <willy@infradead.org>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Aravinda Herle <araherle@in.ibm.com>
Subject: Re: [RFCv2 0/3] iomap: Add support for subpage dirty state tracking to improve write performance
Date: Mon, 30 Jan 2023 18:10:08 +0000 [thread overview]
Message-ID: <Y9gIAKOVAsM2tTZ5@casper.infradead.org> (raw)
In-Reply-To: <cover.1675093524.git.ritesh.list@gmail.com>
On Mon, Jan 30, 2023 at 09:44:10PM +0530, Ritesh Harjani (IBM) wrote:
> TODOs
> ======
> 1. I still need to work on macros which we could declare and use for easy
> reference to uptodate/dirty bits in iop->state[] bitmap (based on previous
> review comments).
I'm not sure it was worth posting this series without doing this, tbh.
> 5. To address one of the other review comments like what happens with a large
> folio. Can we limit the size of bitmaps if the folio is too large e.g. > 2MB.
>
> [RH] - I can start looking into this area too, if we think these patches
> are looking good. My preference would be to work on todos 1-4 as part of this
> patch series and take up bitmap optimization as a follow-up work for next
> part. Please do let me know your thoughts and suggestions on this.
I was hoping to push you towards investigating a better data structure
than a bitmap. I know a bitmap solves your immediate problem since
there are only 16 4kB blocks in a 64kB page, but in a linear-read
scenario, XFS is going to create large folios on POWER machines, all
the way up to 16MB IIUC. Whatever your PMD page size is. So you're
going to be exposed to this in some scenarios, even if you're not seeing
them in your current testing.
next prev parent reply other threads:[~2023-01-30 18:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 16:14 [RFCv2 0/3] iomap: Add support for subpage dirty state tracking to improve write performance Ritesh Harjani (IBM)
2023-01-30 16:14 ` [RFCv2 1/3] iomap: Move creation of iomap_page early in __iomap_write_begin Ritesh Harjani (IBM)
2023-01-30 17:02 ` Christoph Hellwig
2023-01-30 20:21 ` Ritesh Harjani (IBM)
2023-01-30 21:00 ` Matthew Wilcox
2023-01-31 18:37 ` Ritesh Harjani (IBM)
2023-01-31 18:48 ` Matthew Wilcox
2023-01-31 20:00 ` Ritesh Harjani (IBM)
2023-01-30 16:14 ` [RFCv2 2/3] iomap: Change uptodate variable name to state Ritesh Harjani (IBM)
2023-01-30 21:56 ` Dave Chinner
2023-01-30 22:24 ` Matthew Wilcox
2023-01-31 15:07 ` Christoph Hellwig
2023-01-31 18:05 ` Ritesh Harjani (IBM)
2023-01-30 16:14 ` [RFCv2 3/3] iomap: Support subpage size dirty tracking to improve write performance Ritesh Harjani (IBM)
2023-01-30 17:16 ` Christoph Hellwig
2023-01-30 18:01 ` Matthew Wilcox
2023-01-30 20:44 ` Ritesh Harjani (IBM)
2023-01-30 20:27 ` Ritesh Harjani (IBM)
2023-01-30 17:54 ` Matthew Wilcox
2023-01-30 20:34 ` Ritesh Harjani (IBM)
2023-01-30 18:10 ` Matthew Wilcox [this message]
2023-01-30 21:01 ` [RFCv2 0/3] iomap: Add support for subpage dirty state " Ritesh Harjani (IBM)
2023-02-02 4:45 ` Ritesh Harjani (IBM)
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=Y9gIAKOVAsM2tTZ5@casper.infradead.org \
--to=willy@infradead.org \
--cc=araherle@in.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ritesh.list@gmail.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 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).