[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 2/6] xen/x86: move generically usable NUMA code from x86 to common
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Wei Chen <Wei.Chen@xxxxxxx>
- Date: Thu, 29 Sep 2022 15:58:34 +0800
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; 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=fVUB/AKB85Vte6N9diczScXiOxSaW3nHO/laeJK4ofA=; b=FC099LHnmm5nYx8ZdcY0/pIRoYDcJkX9x/QMdlGmsBSV0Ykv/TzC9Un5ncDEqlrnVC8zjix1b3lMtVrzS2hTmw+5/EPIWeC0Y9kenBZHz9mNPLPCXO7jvvZ7Q0vgsqVaWBVg04mu4nk02EOrq1npUL0Zc+yg6nlZO21qPQ2eNquCIeV9GpmUuwI4haThUCAcP+t//75K/CRTwUOdSOyu4I1qdO/IwTHvzYKkuIHyemuHrQJ4PSPSDxJClWHa74W5hj/C2SQrRJ7aPNzUJ+Iy4whSfovSsNkI5SI8TyQ64RveydXTtDjuP8n/56prV/0HjRe7bWAPD0u9y4evpWlX+g==
- 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=fVUB/AKB85Vte6N9diczScXiOxSaW3nHO/laeJK4ofA=; b=LCmx+vl82QyxSHN+kB8lmFtESzne//vJuRVGgr1CComBIdXzizoXnYsrP5eYLRR0X3NxXvBLhSvs3DpfC8ohMmPKd9mqCAlW19AOeX9k9FSLccUoB8F7jq1/zky08DSn9MQ6xgwrYoGPCASUMdoXSe6Bk06V2Q9C5dShgcz6LfFi7K0P3JqHcqNYZV5f4TdnRYTFzJhblajkUI8etHybECWMDKFe6zE51+aWS8tSuGLAhJRxV9CsEIPLy7diflAIDV34vl154WYwbQsYWBKgBgpKAEtgdaQEIsf528o4TiK0wwypv2SYXTomijm2lD3whbBMmh02zWpXxRJgP0hb5w==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=lY3UP9uQVECo3TIErkTdAEm0FG0MA3a6lgcAsjJphzMt/J6d/9QyIB1bo8HJJ2iDKglNjUhEtZDs0JKXUiTatKNIvoi3K/karYXJqa/3zsN4ee9oK9TvvdJB1dB90y0dq9wxtfopHg/IWsdoHcXZU3ZZ7QBPf9t/r65vG7uuI80239oQwQ/a0yAuMQpOglZZ+iSdJc63zbr4ECzMB6bvEYCm2jhyYbse0K0Gix9y6pPqQUMEI2fhGN4HBu+7GRrJxbcZgXajG5J0Q6lEWhWz5rDzzCDMPZcRB7AACIfLhCoTSIyC0L7LYpC787Ar+KDfase6iuMD+s6PY/RQGTFG0g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUfqe7FQGaWOADUHnnl9vW7grI7IyKPH/Z/2DSFWC27FVNdRVXU9fYUDc7sEU8HH5qvIcfH+yLsP3JAL5380FFlN1JsDcXeRJ/L0K9hB8vvCxOjeowxiwNX9b4AOreMM+vX5BddAFaMLhe5tt5Hh9rAg8XF9arCDa1rPDe7CDtPru+09Vj8GYulfBT0752iD4yVwdpRZgnh7kOZwectleXv3e4rLgavt4H7tOagieXYkDC3fm3oPW7Prc+EAzYW4uQobeEvETbwj2MSLnRxmu+Ifuu9y2WrXd8ey4FrFaL7dHl1as/F5t0DzBZF3XIh+fOHBWzxcpED2Uyw3EpYnfw==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: nd@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 29 Sep 2022 07:59:07 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
Hi Jan,
On 2022/9/27 17:39, Jan Beulich wrote:
It's the comment which is wrong - it wasn't updated in Linux commit
54413927f022 ("x86-64: x86_64-make-the-numa-hash-function-nodemap-allocation
fix fix"). Our code was cloned from Linux'es. In fact when memory is not
contiguous, too small a shift value might be determined. This in particular
also may matter for the lowest range covered by any node: On x86 this will
always start at zero (and hence won't influence the final calculation), but
iirc on Arm memory may (and typically will) start at non-zero addresses. In
such a case the first node's start address should be ignored, as it's fine
to (kind of) associate all lower addresses (where no memory is) with this
same node. But that's now indeed something which will want taking care of
while making the code usable for other architectures
Sorry, I hadn't read this before my last reply. I think I kind of
understand what you mean now. If we do not ignore the lowest memory
start address in the node, then the shift we calculate may contain a
part of non-ram physical addresses. But if we ignore it, which address
should we start from? Counting from end may ignore most of the ram area
on this node.
Cheers,
Wei Chen
|
