Re: [uvm_hotplug] Fixing the build of tests

[Jason Thorpe <thorpej%me.com@localhost>]

> On Dec 15, 2018, at 12:51 AM, matthew green <mrg%eterna.com.au@localhost> wrote:
> 
> we have a general problem in UVM we need to confront some time
> fairly soon.  it won't be easy to find all the places, and it
> won't be easy to test we have found them.
> 
> almost all the page counts in UVM are "int".  that overflows
> at 8TiB for 4KiB pages.
> 
> i see that HP have a machine with 48 TiB ram available today.

We can buy ourselves some time on aarch64 by using a different page size, yes?  iOS, for example, uses 16KiB VM pages (backed by 4KiB or 16KiB physical pages, depending on the specific CPU type).  I don't think the ARM eabi has the same section alignment issue that made the 4K/8K page size thing on m68k such a pain.

When you start talking about such large memory configurations, it's not just the size of your pgcnt_t that's an issue, but how well some of your other data structures scale, too.  Simply managing fewer vm_page_t's can help.

> we really need to introduce an MD "page count" type, that we
> can leave as int (or even unsigned -- most uses do not want
> negative values) on most platform, but increase on those with
> massive ram capability (arm64, amd64, ...?).

Yah, I agree that would be a good idea.  I propose "pgcnt_t" as the name.

> (one method to help find violations between old 32 bit values
> and new 64 bit values is to make the 64 bit value a pointer,
> which triggers conversion to different size warnings, and eg,
> display needs a PRIx<PageCountType>, etc., set, as well as
> other things likely to come up.  it seems worth paying the
> price given the almost impossible task of finding all the
> conversions by hand.)

Yah, I think that's a clever trick to use, but I'm not sure it should be kept once the audit / fix-up is complete (unless a really good explanatory comment is included along with it).

-- thorpej