[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/NUMA: correct off-by-1 in node map size calculation
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 29 Sep 2022 16:57:18 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZVQOwU8zTN9mB4zbEtBGlzQz2eWfvIeCIwyb0JHS7Ic=; b=BbEFJUCehlDsS2pkRlL2G7/QHjZYA0cCNXQVXIGviSvGXneTn1zwstR82Yfk37Xn7bOF25ua3MmZ/Uga7WvbRvvKTi/ViMPzJwr60TI6J7tFhzVtyO8Qoz5WiWZySiqftbJ6x2meHIDNnnn+YQBhxARAXlhOTssfMskbQcnhG1yD+igGdnLo8i5NQdgkO8qQnQnWI1+52jvQsaYDW6stu38a+oh3GNrxcour1LVzT9Si2hfg5K31ZrtSx0ZTSr7vAutGvbRhtesZ5QfBW9peJ5rSQ/2h7kip6Uxzai2UI11+laYU+5YnFLTySkd49YTeJmSmOlvi6enxqNQmAweRfA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jh3zgQU1UGG7Ueb2dPn/hoFRSLSuCw0APxOFdLbKzUb4SsX6ny1e/n4BnINEt3w1ya6L/Igfyw+Eo/NfB/4pcizKWRcNASJ01raAU8NZChbCA5BX521ds9EyC7umIr2lvcR7ndkB3097yfj0yQ3/YJ+NH3NgV0XjNopTSBtwgxXKVXB301zuDcJT0FGpVubkyMebW6shcozKQ4sG5NujEWeBsqUpyehKmfqxtl4vU+BOlxNQ7u70gy0U9xFAYdoAv+/Jn+SI5IffekG0oTZiC7SnOntE41obplKenNZIV0Ti/ai9O6gUg8ZFpPk3GUWFqOt8Rq97Lma8ySH2fvmk3w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 29 Sep 2022 14:57:47 +0000
- Ironport-data: A9a23:2VW29KvlDRvNFsOYZjouQkJwMufnVE1fMUV32f8akzHdYApBsoF/q tZmKT2POKncNmHyKdFzb4ji90sA75HQx9cxSQE6+C5hEiwX+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVKiefHgZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI01BjOkGlA5AZmNKoa5AW2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDkkR+ dICdSg9Xiq7pOecy6zgZtZvos0KeZyD0IM34hmMzBn/JNN/GdXvZvuP4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWDilUpj9ABM/KMEjCObd9SkUuC4 HrP4kzyAw0ANczZwj2Amp6prr+Xwn6kAttMfFG+3t83owHUmlMcMz8Pdl2e+tnhu1GXR+sKf iT4/QJr98De7neDTNPwQhm5q36spQMHVpxbFOhSwBGAzO/Y7hiUAkAATyVdc5o2uckuXzso2 1SV2dTzClRHr7m9WX+bsLCOoluP1TM9KGYDYWoISFUD6ty6+IUr1EuXEZBkDbK/icDzFXfo2 TeWoSMihrIVy8kWy6G8+lOBiDWpznTUcjMICszsdjrNxmtEiESNPuRENXCzAS58Ebuk
- Ironport-hdrordr: A9a23:zv8IJK6aI6ayAD6eJQPXwVOBI+orL9Y04lQ7vn2ZFiY5TiXIra qTdaogviMc6Ax/ZJjvo6HkBEClewKlyXcT2/hrAV7CZniehILMFu1fBOTZowEIdxeOldK1kJ 0QCZSWa+eAcmSS7/yKhzVQeuxIqLfnzEnrv5a5854Ed3AXV0gK1XYcNu/0KDwVeOEQbqBJaa Z0q/A30QaISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oC5BOVhT2lxbbmG1zAty1uGw9n8PMHyy zoggb57qKsv7WSzQLd7Xba69BzlMH6wtVOKcSQgow+KynqiCyveIN9Mofy9QwdkaWK0hIHgd PMqxAvM4Ba7G7QRHi8pV/X1wzpwF8Vmgrf4G7dpUGmjd3yRTo8BcYEr5leaAHl500pu8w5+L 5X3kqC3qAnQS/orWDY3ZzlRhtqnk27rT4JiugIlUFSVoMYdft4sZEfxkVIC50NdRiKpbzPKN MeQv002cwmMG9zNxvizylSKZ2XLz4O9y69Mwc/Upf/6UkUoJh7p3FotvD30E1wtq7VcKM0l9 gsAp4Y6o2mcfVmHJ6VJN1xNfdfWVa9Ni7kASa1HWnNMp0hFjbkl6PXiY9Fl91CPqZ4h6cPpA ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Sep 27, 2022 at 04:14:21PM +0200, Jan Beulich wrote:
> extract_lsb_from_nodes() accumulates "memtop" from all PDXes one past
> the covered ranges. Hence the maximum address which can validly by used
> to index the node map is one below this value, and we may currently set
> up a node map with an unused (and never initialized) trailing entry. In
> boundary cases this may also mean we dynamically allocate a page when
> the static (64-entry) map would suffice.
>
> While there also correct the comment ahead of the function, for it to
> match the actual code: Linux commit 54413927f022 ("x86-64:
> x86_64-make-the-numa-hash-function-nodemap-allocation fix fix") removed
> the ORing in of the end address before we actually cloned their code.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> Really the shift value may end up needlessly small when there's
> discontiguous memory. Within a gap, any address can be taken for the
> node boundary, and hence neither the end of the lower range nor the
> start of the higher range necessarily is the best address to use. For
> example with these two node ranges (numbers are frame addresses)
>
> [10000,17fff]
> [28000,2ffff]
>
> we'd calculate the shift as 15 when 16 or even 17 (because the start of
> the 1st range can also be ignored) would do. I haven't tried to properly
> prove it yet, but it looks to me as if the top bit of the XOR of lower
> range (inclusive) end and higher range start would be what would want
> accumulating (of course requiring the entries to be sorted, or to be
> processed in address order). This would then "naturally" exclude lowest
> range start and highest range end.
I'm not familiar with the logic in the NUMA code, seems like a
possible optimization. It might be good to include in which way a
bigger shift is beneficial.
Thanks, Roger.
|
