From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E449C4332E for ; Fri, 20 Mar 2020 16:28:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F52120724 for ; Fri, 20 Mar 2020 16:28:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727536AbgCTQ2l (ORCPT ); Fri, 20 Mar 2020 12:28:41 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:47719 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727163AbgCTQ2k (ORCPT ); Fri, 20 Mar 2020 12:28:40 -0400 Received: from mail-lj1-f181.google.com ([209.85.208.181]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M4bd0-1jEm0n0TIs-001gHZ; Fri, 20 Mar 2020 17:28:39 +0100 Received: by mail-lj1-f181.google.com with SMTP id o10so7060386ljc.8; Fri, 20 Mar 2020 09:28:38 -0700 (PDT) X-Gm-Message-State: ANhLgQ1lXksRDg3jTxH1KKtFuAVYuecGKuXC9CYNcItFdBPNM5EypR0D mxwH6fu9fygVkKi7EYe8BTpg9gbrP93VoADt6II= X-Google-Smtp-Source: ADFU+vvpQzCbtjOU/ac9luh0iy3YFl0a9lDUyyVpQqCoBSJMe7aSkeTdT1zPnEUT/etuCU6Df1Q0pOh+XidX5WSpNxk= X-Received: by 2002:a2e:811a:: with SMTP id d26mr5709626ljg.128.1584721718522; Fri, 20 Mar 2020 09:28:38 -0700 (PDT) MIME-Version: 1.0 References: <1584200119-18594-1-git-send-email-mikelley@microsoft.com> <1584200119-18594-5-git-send-email-mikelley@microsoft.com> <632eb459dbe53a9b69df2a4f030a755b@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Fri, 20 Mar 2020 17:28:22 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 04/10] arm64: hyperv: Add memory alloc/free functions for Hyper-V size pages To: Michael Kelley Cc: Marc Zyngier , gregkh , Will Deacon , Ard Biesheuvel , Catalin Marinas , Mark Rutland , Linux ARM , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , linux-efi , linux-arch , "olaf@aepfle.de" , Andy Whitcroft , vkuznets , Jason Wang , "marcelo.cerri@canonical.com" , KY Srinivasan , Sunil Muthuswamy , Boqun Feng Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:YiwlX9iBdiXNg5xNtCEAFPdb1mkadbK81jrmhX7LRdvitySwwNa I0MZ8RkloQ6Wlcj6yPAZH3KxYFj9R5P8CijRzmi4IEKMRQ3SC3zrS5uqCGDBDEHOSk0BUGw ySjD0RZKR7qkyOKWvFA4tTYRiUyovBuByh3bMx0kN4kQ2pY2R6YP3/gqsSkn9LSJDEGDlqn 1jKT4lbdm9MH/OxBCNijg== X-UI-Out-Filterresults: notjunk:1;V03:K0:p2Q7lJ7StFc=:JDSIaW/ZZxeHgXGY3IgFHv E7dYB81ADyVZu2ueLhAM6M/33RM6j0PlwdFW3oe8a6v5Ifg30WApd8nxrrQr/a7+eg8IQn2iV eLzn+a7Ot5YurHKeqvOKKjW7/s1Ss3BQNIsGrrxDErkTY4ThPFYA0QqYFq4wJcVfRIbWjm/t0 q6UOU9/W8eFKSN1cWIIWZPuQcyOYijM3HfDXk8A3ZPdeebOzLrx9EzF6qYsmbY5WZG4vdLzS6 7zqhMtXadOSRlm2KKytTUJkp8lZtsB4skRcEAS9OURpuHqcyIMLeqpqLh31oygHLvXYzqvX3j jirgTQbb5E8YKufVnzUFBl50/8Vu/ct8u/mjehvzEJQYnVLmNoCIyHmOUmhul1F/Aeej6wzEW /SByQp0/H2S5mmoSlhClYS6d5pvyOF1l+z9woDfb0nSX2yP5cZyMu9sJcN7XfFyHWhwKwRV4g 66+0FxqiTVrDy13KD3mnCw8cp8c2EVnamWhU0NhhynhLW85raJvFloYscH0lb+l4C/IVsvuDE PqfwIiCU6JhTzXxLvHnCBnWN2EW0LvvHLYBBLMBqCZlb6K9eMtqObq7/AIahoH8rzZiZd5/fD zEjVbKoc3VeqwIzN2dfVoha57MZ5NjX6cfZSA9+SFKK7qKWBFNckCf9cqKyLnrLKqZc+LTlgd rbh7W37ozfk8r++8aYM3kHdGJ2eRMk6Y3NFGlqEuzyZmg85GyO93VyHQuw2hQbk8LYF4F6eEG O4E7Rc+g1yCcnL5vyfT+wULZf+LNNZOGrEuwnrW0PVxWc/D7HohvhLTSQ6OjCffx0gQSgZCJG dR9naK66fvrP5fTFu1dGR/9upk6iUh6zUNJ0Ki8+p9EJ9ohoiM= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2020 at 10:43 PM Michael Kelley wrote: > From: Arnd Bergmann Sent: Wednesday, March 18, 2020 2:58 AM > > On Wed, Mar 18, 2020 at 1:15 AM Michael Kelley wrote: > > My point was to keep the functions but use alloc_pages() internally, > > so you can deal with the hypervisor having a larger page size than > > the guest, which seems to be a more important scenario if I correctly > > understand the differences between the way Windows and Linux > > deal with page cache. > > OK, I see now what you are getting at. I should spell out my > assumption, which is the opposite. Hyper-V won't have a page > size other than 4K anytime in the foreseeable future. The > code is too wedded to the x86 4K page size, and the host-guest > interfaces have a lot of implicit assumptions that the page size is > 4K (unfortunately). But the last time I looked, RHEL for ARM64 is > delivered with a 64K page size. So my assumption is that the only > combination that really matters is the guest page size being larger > than the Hyper-V page size. The other way around just won't > happen without a major overhaul to Hyper-V, including a rework > of the guest-host interface. Ok, got it. We should really ask Red Hat to change the page size, but as long as you care existing systems, and you expect this to result in gigabytes of allocation on future systems, having the wrapper seems reasonable. Maybe you could fall back to alloc_page when PAGE_SIZE equals HV_HYP_PAGE_SIZE though? I'm not sure what the tradeoff between kmalloc and alloc_page is these days, other than the feeling that alloc_page is the more obvious choice when you know you always want exactly a page here. Arnd