[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/9] xen/x86: Use enumerations to indicate NUMA status
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Wei Chen <Wei.Chen@xxxxxxx>
- Date: Mon, 25 Jul 2022 10:28:52 +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=YLuCzy+cN/I3v4U/f4R0TTbIF/bAwTpA+wkmXDvyB98=; b=bIdSH680XTuglP2vxSVM4eOn7/NWln1xYzaEb7qnJgHgs1sl3xtsRuG3ApuQVxFYyCAruRda83NStorRBUBWZv+flbaYfr1gmnVa9HFJq88sOftR5PWs7GLpxZxOVk7Heggeb/6zrhT/yh4vcJsUZvknPRVaNjQ3JtKhRGk7keyCFNrn/QsEcinlbvL3dnS87qf6L7j2M5caIgbRfyG4foJ70goTF1KBBBczQayVxACbH1fDRVDh8gGcZBKSzTZjDV6ofIyHAkLAaSN0Y7R0uCqgbxxnJQdIixqKWLXKQYoZnYvbypVSG88zrb2euCRKGMbiWbIsr6ayxtMxNNTRlg==
- 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=YLuCzy+cN/I3v4U/f4R0TTbIF/bAwTpA+wkmXDvyB98=; b=HTZ7go/UBUReQ/U3nv5fvBdZUSHngfCdBvoSz7S/eGWVSwhNCZLzoyjg/rBhLFpewS3QjwnuffhetJ2ojR7v1SPWxuP5nyMuCdlrueDPP7COfh+Nwcj/MIPY4PTFn9oHD55hPtk1rN3iz6dEJ7Av111dZXU9cBEbHxY94sXGSj2RLwIf5GfFSf5nDmht7dkJ725a7qp+kv/3wXJeM1508ZIaXXpGW+hVhb/wzMpqKhf01ZMAyzuW7SZKPBAPIqyfN0wy5VTevxGOQMbN6ou4O1NwFylOvSFU5nZV1FuhPE1yyw+D5Kj8J9Ime3yoDrKrwn1hp54xjQecQCyXPEcltw==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=LRDpEtbquqbKlZP6CJIrdW2BhesLKbM1i86l/Hzm5jej2LVUQ9v5FoSHn6KTlMb5X6x7ehF1IbtCH5xfJUPpONdlWgGi23l9iQ4zlKvjhgIBJOZ9XYO088/VkJwrqNXQI85KMVcfvdOHftmZtPeN/DmIuQWbHlkYzrFlnHbaOUs9tT9gQrIGjtGqcemUbAsuWUkr4vPJrrDqQWJ+gD+ugk+tajibajqY8cFqYIKK1Yhu76qnr06viDM36WD/ZEPboSGq+4X5pFGNVniMLV0RB2FDmYintSkD0VzaOIUVBDzWbi6oMwcjjNbKctwBcTkA3pSpaQn91Md9xT5zxR+0dA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m91sS+XV/fgIZp2OCDH2FPK81Rb6MEcwqaC0hmBIVjuzFOrDQlzG4nOIIqmRTx9MjLV03dwcHli9SvMfNTCT3Ilfx2LOIZKXcK8fPSt8XwQDdCfp+WeWOPZ/xaLXss8054dd0sICn0zMI0BGxFAP/pWzxt0tkQyci6htdKyoYZKwsxf8A8UuEKUE9uHLEuFm47Jk0CtTn1z+YHh1p59A6UDWlUi4BI5Gs66KEINysquXkTsCmGrEpCdoNgKDBkZA5d8iFiXM/4AHKV1VUSUopLcukjU5/qNJHPruLaxz+8shm90p1Y7rV10w6ILyXcWsDd4VzZS7Ixd8Vl9sxqKG2w==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: nd <nd@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 25 Jul 2022 02:29:22 +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/7/14 18:51, Jan Beulich wrote:
No matter how many separate "numa=" parameters have been parsed from
Command line, the values of these original variables are determined
after parsing the command line. So the determined status can be mapped
to the new one variable from above table.
Hmm, I was partly wrong - the initial values of both variables are
indeed set from just the single "numa=" parsing. But later on they
"evolve" independently, and multiple "numa=" on the command line
can also have "interesting" effects. I'm afraid I still can't
convince myself that the new mapping fully represents all originally
possible combinations (nor can I convince myself that in the existing
code everything is working as intended).
Maybe the solution is to make numa_off common but keep acpi_numa
arch-specific? Then e.g. the replacement of srat_disabled() could
be
int numa_disabled(void)
{
return numa_off || arch_numa_disabled();
}
with arch_numa_disabled() evaluating acpi_numa on x86.
While I am working on the new version, I think this may be not enough,
we may need another helper like arch_handle_numa_param to prevent direct
accessing of acpi_numa in numa_setup.
Cheers,
Wei Chen
Jan
|
