On Thu, Mar 19, 2020 at 10:43 PM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote:
> From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Wednesday, March 18, 2020 2:58 AM
> > On Wed, Mar 18, 2020 at 1:15 AM Michael Kelley <mikelley@xxxxxxxxxxxxx> 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
