From: Sumitra Sharma <sumitraartsy@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Ira Weiny <ira.weiny@intel.com>, Fabio <fmdefrancesco@gmail.com>,
Deepak R Varma <drv@mailo.com>,
Sumitra Sharma <sumitraartsy@gmail.com>
Subject: Re: [PATCH] fs/vboxsf: Replace kmap() with kmap_local_{page, folio}()
Date: Thu, 29 Jun 2023 02:28:44 -0700 [thread overview]
Message-ID: <20230629092844.GA456505@sumitra.com> (raw)
In-Reply-To: <ZJxqmEVKoxxftfXM@casper.infradead.org>
On Wed, Jun 28, 2023 at 06:15:04PM +0100, Matthew Wilcox wrote:
> Here's a more comprehensive read_folio patch. It's not at all
> efficient, but then if we wanted an efficient vboxsf, we'd implement
> vboxsf_readahead() and actually do an async call with deferred setting
> of the uptodate flag. I can consult with anyone who wants to do all
> this work.
>
> I haven't even compiled this, just trying to show the direction this
> should take.
>
> diff --git a/fs/vboxsf/file.c b/fs/vboxsf/file.c
> index 2307f8037efc..f1af9a7bd3d8 100644
> --- a/fs/vboxsf/file.c
> +++ b/fs/vboxsf/file.c
> @@ -227,26 +227,31 @@ const struct inode_operations vboxsf_reg_iops = {
>
> static int vboxsf_read_folio(struct file *file, struct folio *folio)
> {
> - struct page *page = &folio->page;
> struct vboxsf_handle *sf_handle = file->private_data;
> - loff_t off = page_offset(page);
> - u32 nread = PAGE_SIZE;
> - u8 *buf;
> + loff_t pos = folio_pos(folio);
> + size_t offset = 0;
> int err;
>
> - buf = kmap(page);
> + do {
> + u8 *buf = kmap_local_folio(folio, offset);
> + u32 nread = PAGE_SIZE;
>
> - err = vboxsf_read(sf_handle->root, sf_handle->handle, off, &nread, buf);
> - if (err == 0) {
> - memset(&buf[nread], 0, PAGE_SIZE - nread);
> - flush_dcache_page(page);
> - SetPageUptodate(page);
> - } else {
> - SetPageError(page);
> - }
> + err = vboxsf_read(sf_handle->root, sf_handle->handle, pos,
> + &nread, buf);
> + if (nread < PAGE_SIZE)
> + memset(&buf[nread], 0, PAGE_SIZE - nread);
> + kunmap_local(buf);
> + if (err)
> + break;
> + offset += PAGE_SIZE;
> + pos += PAGE_SIZE;
> + } while (offset < folio_size(folio);
>
> - kunmap(page);
> - unlock_page(page);
> + if (!err) {
> + flush_dcache_folio(folio);
> + folio_mark_uptodate(folio);
> + }
> + folio_unlock(folio);
> return err;
> }
>
Hi
So, after reading the comments, I understood that the problem presented
by Hans and Matthew is as follows:
1) In the current code, the buffers used by vboxsf_write()/vboxsf_read() are
translated to PAGELIST-s before passing to the hypervisor,
but inefficiently— it first maps a page in vboxsf_read_folio() and then
calls page_to_phys(virt_to_page()) in the function hgcm_call_init_linaddr().
The inefficiency in the current implementation arises due to the unnecessary
mapping of a page in vboxsf_read_folio() because the mapping output, i.e. the
linear address, is used deep down in file 'drivers/virt/vboxguest/vboxguest_utils.c'.
Hence, the mapping must be done in this file; to do so, the folio must be passed
until this point. It can be done by adding a new member, 'struct folio *folio',
in the 'struct vmmdev_hgcm_function_parameter64'.
The unused member 'phys_addr' in this struct can also be removed.
2) Expanding the vboxsf_read_folio so that it can handle larger folios.
Matthew already has suggested the changes, I have to read more on this.
Parallelly I will be setting up the testing environment to test the changes.
Please let me know if I am wrong anywhere.
Thanks & regards
Sumitra
next prev parent reply other threads:[~2023-06-29 9:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 13:51 [PATCH] fs/vboxsf: Replace kmap() with kmap_local_{page, folio}() 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
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 [this message]
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=20230629092844.GA456505@sumitra.com \
--to=sumitraartsy@gmail.com \
--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=willy@infradead.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 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.