From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Friday, March 20, 2020 9:28 AM > > 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. > Yes, that works for me. Michael
