From: Matthew Wilcox <willy@infradead.org>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: Sumitra Sharma <sumitraartsy@gmail.com>,
Hans de Goede <hdegoede@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Ira Weiny <ira.weiny@intel.com>, Deepak R Varma <drv@mailo.com>
Subject: Re: [PATCH] fs/vboxsf: Replace kmap() with kmap_local_{page, folio}()
Date: Thu, 29 Jun 2023 04:16:04 +0100 [thread overview]
Message-ID: <ZJz3dO10o9+xV65F@casper.infradead.org> (raw)
In-Reply-To: <6924669.18pcnM708K@suse>
On Thu, Jun 29, 2023 at 12:23:54AM +0200, Fabio M. De Francesco wrote:
> > - buf = kmap(page);
> > + do {
>
> Please let me understand why you are calling vboxsf_read() in a loop, a
> PAGE_SIZE at a time.
Because kmap_local_folio() can only (guarantee to) map one page at a
time. Also vboxsf_read() is only tested with a single page at a time.
> If I understand the current code it reads a single page at offset zero of a
> folio and then memset() with zeros from &buf[nread] up to the end of the page.
> Then it seems that this function currently assume that the folio doesn't need
> to be read until "offset < folio_size(folio)" becomes false.
>
> Does it imply that the folio is always one page sized? Doesn't it? I'm surely
> missing some basics...
vboxsf does not yet claim to support large folios, so every folio that
it sees will be only a single page in size. Hopefully at some point
that will change. Again, somebody would need to test that. In the
meantime, if someone is going to the trouble of switching over to using
the folio API, let's actually include support for large folios.
> > - kunmap(page);
> > - unlock_page(page);
> > + if (!err) {
> > + flush_dcache_folio(folio);
> > + folio_mark_uptodate(folio);
> > + }
> > + folio_unlock(folio);
>
> Shouldn't we call folio_lock() to lock the folio to be able to unlock with
> folio_unlock()?
>
> If so, I can't find any neither a folio_lock() or a page_lock() in this
> filesystem.
>
> Again sorry for not understanding, can you please explain it?
Ira gave the minimal explanation, but a slightly fuller explanation is
that the folio is locked while it is being fetched from backing store.
That prevents both a second thread from reading from it while another
thread is bringing it uptodate, and two threads trying to bring it
uptodate at the same time.
Most filesystems have an asynchronous read_folio, so you don't see the
folio_unlock() in the read_folio() function; instead it's in the I/O
completion path. vboxsf is synchronous.
next prev parent reply other threads:[~2023-06-29 3:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 13:51 Sumitra Sharma
2023-06-27 14:34 ` Hans de Goede
2023-06-27 17:46 ` Matthew Wilcox
2023-06-27 18:10 ` Hans de Goede
2023-06-27 18:19 ` Hans de Goede
2023-06-27 17:48 ` Matthew Wilcox
2023-06-27 18:04 ` Hans de Goede
2023-06-29 4:30 ` Sumitra Sharma
2023-06-29 5:35 ` Hans de Goede
2023-06-28 17:15 ` Matthew Wilcox
2023-06-28 22:23 ` Fabio M. De Francesco
2023-06-28 22:40 ` Fabio M. De Francesco
2023-06-29 2:13 ` Ira Weiny
2023-06-29 3:16 ` Matthew Wilcox [this message]
2023-06-29 15:04 ` Fabio M. De Francesco
2023-06-29 2:23 ` Ira Weiny
2023-06-29 3:08 ` Matthew Wilcox
2023-06-29 9:28 ` Sumitra Sharma
2023-06-29 10:01 ` Hans de Goede
2023-06-29 14:42 ` Matthew Wilcox
2023-06-29 15:01 ` Hans de Goede
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=ZJz3dO10o9+xV65F@casper.infradead.org \
--to=willy@infradead.org \
--cc=drv@mailo.com \
--cc=fmdefrancesco@gmail.com \
--cc=hdegoede@redhat.com \
--cc=ira.weiny@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sumitraartsy@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
all inboxes | Powered by JetHome®