re: [uvm_hotplug] Fixing the build of tests

[matthew green <mrg%eterna.com.au@localhost>]

semi-related, but perhaps a change to begin marking places we
need to fix...

> The reason for failure was the comparison between psize_t (which is
> defined as unsigned log inside t_uvm_hotplug.c) and int resulting in a
> sign compare error (-Werror=sign-compare). This was used to compare
> the "npages"  variable inside uvmexp struct.
> 
> I have fixed the build by doing a type cast of uvmexp.npages to
> psize_t and the changes have been attached as diff along with this
> mail. The rationale for this is that uvmexp.npages is not expected to
> go below zero and hence the type cast does not result in negative
> values being converted to unsigned long.

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 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, ...?).

(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.)


.mrg.