[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/NUMA: improve memnode_shift calculation for multi node system


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 30 Sep 2022 14:05:38 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=RA5Xpy1wR8IWHIfULTS1aAulT92HxfuCIyp3kr9DfCU=; b=ft2smnQGxf9UhyonMfoMhsMWVrx/Q6q5nqugY5BpZQwWTEwT6LElaPs++6FJgHdL7WpiKGyUGtgUG+TOGOqTC32kFaD+sQ94NwVABscMKKgqjg/j4I2HLTr2fzYI7hjXFUybgpdQhWipbYlsl2n/fqKeGIoGSg90OwCLQZpDl7PEDn9NJGUBWgr9VH0EwKBwhEfROWyvycOnRS7Kl9BEJxUYKArws2SdTI1WEAGdwuSQhii/etqsWBQ14CUGRcLcT7rGDDmHniw4mBjPPyWNjf1FNt3QBCXe0VXovdVvVNPR2e9Dknrc+UzgC/foajk2UCdep33bWuLDIYRSZ2ZN8A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OLqj6hGi2IxAiMbgvhNYLM1FPENQ3bBclC+OBjKehSlU0aEqiv9jWt1TYIy0C/OKausc/tTi5XPjVr0ZUQAu4jKGU8WhDinURR8AheO394lb/vQczp1fcWVWhE6x1pgMAy89uWe2h99GSuA4Cys9Vhaqo/ML+u4dphGa7+1QordUrskDZbUdYHxNWZKWPS17iAKhp5XSUMLCG1OVPXWvhyCuPvldIoWf9GYa538+syWA2ImB5CEiEchjG64Uv0dDG8ArDJQtglqTrMa3fFb8/TLZWOrYo0LFnCZDpzs/c4r9bZdzj+3cydRGMpQoYyjOszT+YW0Y4PcFHwc6FFyxhQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 30 Sep 2022 12:05:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.09.2022 13:54, Andrew Cooper wrote:
> On 27/09/2022 17:20, Jan Beulich wrote:
>> --- a/xen/arch/x86/srat.c
>> +++ b/xen/arch/x86/srat.c
>> @@ -413,14 +414,37 @@ acpi_numa_memory_affinity_init(const str
>>             node, pxm, start, end - 1,
>>             ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE ? " (hotplug)" : "");
>>  
>> -    node_memblk_range[num_node_memblks].start = start;
>> -    node_memblk_range[num_node_memblks].end = end;
>> -    memblk_nodeid[num_node_memblks] = node;
>> +    /* Keep node_memblk_range[] sorted by address. */
>> +    for (i = 0; i < num_node_memblks; ++i)
>> +            if (node_memblk_range[i].start > start ||
>> +                (node_memblk_range[i].start == start &&
>> +                 node_memblk_range[i].end > end))
>> +                    break;
>> +
>> +    memmove(&node_memblk_range[i + 1], &node_memblk_range[i],
>> +            (num_node_memblks - i) * sizeof(*node_memblk_range));
>> +    node_memblk_range[i].start = start;
>> +    node_memblk_range[i].end = end;
>> +
>> +    memmove(&memblk_nodeid[i + 1], &memblk_nodeid[i],
>> +            (num_node_memblks - i) * sizeof(*memblk_nodeid));
>> +    memblk_nodeid[i] = node;
> 
> This is now the 4th example we have of logic wanting a sorted array. 
> (two examples in ARM code which want to switch away from using sort(),
> and the VMX MSR lists).
> 
> I was already contemplating doing a small library (static inline, or
> perhaps extern inline now we've started using that) to abstract away the
> insert/find/delete operations and their decidedly non-trivial pointer
> operations.

For using such library routines the data structures here would need
re-organizing first: We're inserting into two arrays and a bitmap at
the same time.

> The secondary purpose was to be able to do some actual unit tests of the
> library, so we can be rather better assured of correctness.
> 
> 
> For this case, and the two ARM cases, the firmware data is supposed to
> be sorted to begin with, so the search-for-insertion loop should look at
> the num_node_memblks entry first because the overwhelming common case is
> that the end is the correct place to put it.  If not, it should binary
> search backwards rather than doing a linear search.

Well, yes, perhaps. Of course we don't expect there to be very many
entries, at which point I guess a linear search can be deemed acceptable.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.