Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp20502554rwd; Thu, 29 Jun 2023 03:15:36 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7/wc95TfcddD3RjU6wvOb8OULgWB2JoDFxhSN8137sOa/tDvadRuaqw2r+X3j9yxDQdiZz X-Received: by 2002:a17:902:da84:b0:1b6:78a1:93c7 with SMTP id j4-20020a170902da8400b001b678a193c7mr13820368plx.39.1688033736340; Thu, 29 Jun 2023 03:15:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688033736; cv=none; d=google.com; s=arc-20160816; b=LPL5o3qj06zaDo7XLd152WKWZPbqFoqBg4zp/ZiaMDM6eobEn1V4BX6JvSl7Db3b/o bRIHmbKI8rUXA+zkso99aWTCeeavTUqrKS+TSSDTuIANYhU9W3QLxusweEJK2XWzmqeP xWcXlyk+ERwpOIDk/E4uq0Yheisd4EkpFYn73fwFKrXFF3CkC9YQUOb6/Ou8t40qeGUM HbckbkQKvnrZNkpWYUp3Zcyhg6q15Cas07jvXOB/8XCgkNl7ZYHfGc8oFjTnUkYCGPeL L1mReKjZHi97ZGh8o+OZk5n+opG1kPEeKQkmpKT/dHbCZqFHsJBIPiNQ4TN96G+TllmX 3PZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=F09uj+UaHNEb8AMaOUGwCKDcEHZfFZHJu8wPUUcwCrI=; fh=ARAAWvYvHGNkeW5aBxmZSWKVx31wvNOzDTgH7vuMlr8=; b=GoVholQ95zHopuz3wcy3jWMp89zq5013P6ab1NNU2t9+q1Zm9H7S5oxeRcgqZgkkky MI7Beuzz66Tdc7iAiqmsT69zkWw2KPTP+5++cGH5Y74GGvBF00A5UWrgcngOqI3KHjk0 Od419LKW+kIAQ11GjBa6oynDKiZwDOC7uMTScXGwdz7iLHOOlapypbrQ+DCWUsSfEOXb S3anvjGFeIdhO8Aa/ZLe193KjwZg/7AG8qBImCBogzN3eyFhnDWhNElbSgaGTG7XkjuN NVbjc2eWf0YPgC514EKChB3pqGj1FxLg/RnysoAuX2tdA93ftmuOWjtPg1/FuyyN68CD iDFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=d+YfaBew; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s13-20020a170903200d00b001b86493ae11si112822pla.559.2023.06.29.03.15.24; Thu, 29 Jun 2023 03:15:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=d+YfaBew; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232212AbjF2KGl (ORCPT + 99 others); Thu, 29 Jun 2023 06:06:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231987AbjF2KEa (ORCPT ); Thu, 29 Jun 2023 06:04:30 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1131F3C3A for ; Thu, 29 Jun 2023 03:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688032917; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F09uj+UaHNEb8AMaOUGwCKDcEHZfFZHJu8wPUUcwCrI=; b=d+YfaBewQtNZ8spEyXpsJKYj1YuSTUQ2FMWOPeKC8LA1ZFfhgxbH68I0Us2aMfNr2czq/F K3FsW7yYzKIizcyUUfygesbpT+D7Rx7tHFeUwTZsfWMKF5vZe5XlQszBNRyITl9OOI0mbq ARgzqbH1fKFDIHwNqRFb2huX6RFE0JA= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-JO9UBSLjMSmJ2sWunr42Ow-1; Thu, 29 Jun 2023 06:01:56 -0400 X-MC-Unique: JO9UBSLjMSmJ2sWunr42Ow-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-94f7a2b21fdso53123466b.2 for ; Thu, 29 Jun 2023 03:01:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688032915; x=1690624915; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=F09uj+UaHNEb8AMaOUGwCKDcEHZfFZHJu8wPUUcwCrI=; b=E7YE5+45IPGxxbexW4QghUdyqphNrOWND6+ydGElcpDY59PRETRtS8tqEx+JWnvV0L 8W5AzGGpjnteWRf10meyTkHvolUbiRZ9K4iTHkqXfPsfybkPZu2t2C6qdocMY/zf6AMu PBX+k2C1638llGFwgmaLS0RANL9Wr6VaI5/+3p8p1QgDkki4oQo8gaaON6jF0isF/CCK 4ftJte0D/4dpgL7iH1UG+jmg4uSwF1AYAlHImVCn4oQdKclzFE0FLcgIitiWbo74xc21 wgyoeUVz3x1+79+hPmSYytvEjEvKHKPqCopAi6d81oO4H8aUTH5WLd3SBpAxdfOdey1q 9SyQ== X-Gm-Message-State: AC+VfDwfdLQ0CEUsz2FGW7Ubq6Ylr9zrIU00cDwgd6zG0x+MZAF/Ii/m SzTC07+1CpExNfguW5WskLL+6NFJfHYJ6PkuDtnY8bdF1Rs/Uj7qsk20S8Ugq0R8YbK3uqZVbM1 euzXP4UT2Hegxr3dNDmcHB8F275N6RRip X-Received: by 2002:a17:907:983:b0:94e:2db:533e with SMTP id bf3-20020a170907098300b0094e02db533emr37548545ejc.49.1688032915023; Thu, 29 Jun 2023 03:01:55 -0700 (PDT) X-Received: by 2002:a17:907:983:b0:94e:2db:533e with SMTP id bf3-20020a170907098300b0094e02db533emr37548526ejc.49.1688032914761; Thu, 29 Jun 2023 03:01:54 -0700 (PDT) Received: from ?IPV6:2001:1c00:2a07:3a01:67e5:daf9:cec0:df6? (2001-1c00-2a07-3a01-67e5-daf9-cec0-0df6.cable.dynamic.v6.ziggo.nl. [2001:1c00:2a07:3a01:67e5:daf9:cec0:df6]) by smtp.gmail.com with ESMTPSA id rl14-20020a170907216e00b00992ab0262c9sm679883ejb.147.2023.06.29.03.01.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jun 2023 03:01:54 -0700 (PDT) Message-ID: <3105fb11-b599-73c9-5a7b-895ef384a2e3@redhat.com> Date: Thu, 29 Jun 2023 12:01:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH] fs/vboxsf: Replace kmap() with kmap_local_{page, folio}() Content-Language: en-US To: Sumitra Sharma , Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ira Weiny , Fabio , Deepak R Varma References: <20230627135115.GA452832@sumitra.com> <20230629092844.GA456505@sumitra.com> From: Hans de Goede In-Reply-To: <20230629092844.GA456505@sumitra.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 6/29/23 11:28, Sumitra Sharma wrote: > 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'. struct vmmdev_hgcm_function_parameter64 is defined in include/uapi/linux/vbox_vmmdev_types.h This is part of the userspace API of vboxguest which allows userspace to make (some) VirtualBox hypervisor request through a chardev. You can not just go and change this struct. Note there already is a VMMDEV_HGCM_PARM_TYPE_PAGELIST type. So you could do the conversion from folio to pagelist (see the vboxguest code for how to do this) in the vboxsf_read() code (making it take a folio pointer as arg) and then directly pass the pagelist to the vbg_hgcm_call(). > The unused member 'phys_addr' in this struct can also be removed. Again no you can NOT just go and make changes to an uapi header. Regards, Hans