On 11/01/2023 1:56 pm, Jan Beulich wrote: > The "n" input is a GFN/MFN value and hence bounded by the physical > address bits in use on a system. The hash quality won't improve by also > including the upper always-zero bits in the calculation. To keep things > as compile-time-constant as they were before, use PADDR_BITS (not > paddr_bits) for loop bounding. This reduces loop iterations from 8 to 5. > > While there also drop the unnecessary conversion to an array of unsigned > char, moving the value off the stack altogether (at least with > optimization enabled).
I'm not sure this final bit in brackets is relevant. It wouldn't be on the stack without optimisations either, because ABI-wise, it will be in %rsi. I'd just drop it. > > Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Andrew Cooper <[email protected]>
