From: Matthew Wilcox <willy@infradead.org>
To: Kundan Kumar <kundan.kumar@samsung.com>
Cc: axboe@kernel.dk, hch@lst.de, linux-block@vger.kernel.org,
joshi.k@samsung.com, mcgrof@kernel.org, anuj20.g@samsung.com,
nj.shetty@samsung.com, c.gameti@samsung.com,
gost.dev@samsung.com
Subject: Re: [PATCH v3 2/3] block: add folio awareness instead of looping through pages
Date: Wed, 15 May 2024 21:55:26 +0100 [thread overview]
Message-ID: <ZkUhPoWnvxPYONIA@casper.infradead.org> (raw)
In-Reply-To: <20240507144509.37477-3-kundan.kumar@samsung.com>
On Tue, May 07, 2024 at 08:15:08PM +0530, Kundan Kumar wrote:
> Add a bigger size from folio to bio and skip processing for pages.
>
> Fetch the offset of page within a folio. Depending on the size of folio
> and folio_offset, fetch a larger length. This length may consist of
> multiple contiguous pages if folio is multiorder.
The problem is that it may not. Here's the scenario:
int fd, fd2;
fd = open(src, O_RDONLY);
char *addr = mmap(NULL, 1024 * 1024, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_HUGETLB, fd, 0);
int i, j;
for (i = 0; i < 1024 * 1024; i++)
j |= addr[i];
addr[30000] = 17;
fd2 = open(dest, O_RDWR | O_DIRECT);
write(fd2, &addr[16384], 32768);
Assuming that the source file supports being cached in large folios,
the page array we get from GUP might contain:
f0p4 f0p5 f0p6 f1p0 f0p8 f0p9 ...
because we allocated 'f1' when we did COW due to the store to addr[30000].
We can certainly reduce the cost of merge if we know two pages are part
of the same folio, but we still need to check that we actually got
pages which are part of the same folio.
next prev parent reply other threads:[~2024-05-15 20:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240507145232epcas5p481986099a82b1880758b7770cdeaf2d2@epcas5p4.samsung.com>
2024-05-07 14:45 ` [PATCH v3 0/3] block: add larger order folio instead of pages Kundan Kumar
2024-05-07 14:45 ` [PATCH v3 1/3] nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset Kundan Kumar
2024-05-23 8:51 ` Christoph Hellwig
2024-05-23 10:07 ` Kundan Kumar
2024-05-07 14:45 ` [PATCH v3 2/3] block: add folio awareness instead of looping through pages Kundan Kumar
2024-05-15 20:55 ` Matthew Wilcox [this message]
2024-05-24 9:22 ` Kundan Kumar
2024-05-24 15:40 ` Matthew Wilcox
2024-05-07 14:45 ` [PATCH v3 3/3] block: unpin user pages belonging to a folio Kundan Kumar
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=ZkUhPoWnvxPYONIA@casper.infradead.org \
--to=willy@infradead.org \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=c.gameti@samsung.com \
--cc=gost.dev@samsung.com \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=kundan.kumar@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=nj.shetty@samsung.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