From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Richter Subject: Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init() Date: Thu, 28 Jan 2016 14:31:08 +0100 Message-ID: <20160128133108.GY24726@rric.localdomain> References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com> <1453541967-3744-13-git-send-email-guohanjun@huawei.com> <20160125102643.GF24726@rric.localdomain> <56A8606A.8080407@huawei.com> <20160127141847.GR24726@rric.localdomain> <56A98185.4080202@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Received: from mail-by2on0094.outbound.protection.outlook.com ([207.46.100.94]:57120 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750880AbcA1Nb0 (ORCPT ); Thu, 28 Jan 2016 08:31:26 -0500 Content-Disposition: inline In-Reply-To: <56A98185.4080202@huawei.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Hanjun Guo Cc: "Rafael J. Wysocki" , Will Deacon , Catalin Marinas , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Ganapatrao Kulkarni , Lorenzo Pieralisi , Shannon Zhao , Steve Capper , Mark Rutland , Hanjun Guo On 28.01.16 10:48:37, Hanjun Guo wrote: > On 2016/1/27 22:18, Robert Richter wrote: > > On 27.01.16 14:15:06, Hanjun Guo wrote: > >> Hi Robert, > >> > >> On 2016/1/25 18:26, Robert Richter wrote: > >>> On 23.01.16 17:39:27, Hanjun Guo wrote: > >>>> From: Hanjun Guo > >>>> > >>>> After the cleanup for acpi_numa_memory_affinity_init(), > >>>> it can be used for architetures both x86 and arm64, since > >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no > >>>> worry about that. > >>>> > >>>> Signed-off-by: Hanjun Guo > >>>> --- > >>>> arch/arm64/kernel/acpi_numa.c | 42 ------------------------------- > >>>> arch/x86/mm/srat.c | 54 ---------------------------------------- > >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++ > >>>> 3 files changed, 57 insertions(+), 96 deletions(-) > >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version. > >>> I rather would prefer the arm64 version for the generic code. We could > >>> keep the x86 implementation until x86 maintainers agree to remove them > >>> and use the generic one (implemented in a separate patch). > >>> > >>> Doing so we can move acpi_numa_memory_affinity_init() from the > >>> beginning to generic code (used for arm64) and have this last patch to > >>> remove the x86 version. > >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and > >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features. > >> For ARM64, firmware should be careful and represent the true platform configuration to > >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support > >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right, > >> it will be not worries for the kernel. > > But you are removing all arm64 from your first patches. Why do you > > introduce acpi_numa_memory_affinity_init() in the beginning to remove > > it in the end again? I esp. like the arm64 version because of its > > direct returns. So I still would like to see generic code for arm64 > > from the beginning. Maybe have a copy of x86 initially and make > > modifications for arm64 to it, or move missing code (hotplug, etc.) > > from x86 to generic and remove x86 arch code with the last patch. > > OK, so that's the logic and ordering of formatting the patch set, it's easy > to fix :) > > I will introduce the generic code for acpi_numa_memory_affinity_init() > in drivers/acpi/numa.c and mark it as __weak from the beginning, and > move missing code from x86 to generic, then remove x86 one as you > suggested, is that OK? Sounds good to me. Awaiting your updated version. :) Btw, I tested the whole series, so: Tested-by: Robert Richter -Robert From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755231AbcA1Nba (ORCPT ); Thu, 28 Jan 2016 08:31:30 -0500 Received: from mail-by2on0094.outbound.protection.outlook.com ([207.46.100.94]:57120 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750880AbcA1Nb0 (ORCPT ); Thu, 28 Jan 2016 08:31:26 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Robert.Richter@caviumnetworks.com; Date: Thu, 28 Jan 2016 14:31:08 +0100 From: Robert Richter To: Hanjun Guo CC: "Rafael J. Wysocki" , Will Deacon , Catalin Marinas , , , , Ganapatrao Kulkarni , Lorenzo Pieralisi , Shannon Zhao , Steve Capper , Mark Rutland , Hanjun Guo Subject: Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init() Message-ID: <20160128133108.GY24726@rric.localdomain> References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com> <1453541967-3744-13-git-send-email-guohanjun@huawei.com> <20160125102643.GF24726@rric.localdomain> <56A8606A.8080407@huawei.com> <20160127141847.GR24726@rric.localdomain> <56A98185.4080202@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <56A98185.4080202@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [78.53.85.173] X-ClientProxiedBy: AM3PR01CA059.eurprd01.prod.exchangelabs.com (10.141.191.49) To CY1PR0701MB1615.namprd07.prod.outlook.com (25.163.20.152) X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1615;2:ME/A/xFx9KNNXivn4Pq4BCBkz3det2FfE5erIcrrYtw0bPPdSrltuFO4MaHSfYJCKwyhzvJjgFf4y5lxDRLjZOxi3g11BB2A95Trs/7OpQikT1NGjvLmtQ/QogSnTBWtgO1JhoUPH8rMeZ7Xwk5Iwg==;3:CtaQu6VG4ksErN1AKCbBcleTnSBvEnruViq9nA+MjHGnn5kGw+UlQ0HWLe9Ig6h6UZ7dONiBDI7lrd4qiEsmwLwMpJ0UpbrCKMxIy/G2fs1wQuKRW0vUtgY9PvhTPDHD;25:6u11XdxjtkhyoPHODGhv9nciRVvLVf7IGZUYG5iioe+hDLOSjck7pog9TD+SU1O2hDXYF56TNAQBERuM5DkUrpLfI5NUyfueE1iudUKB9HHIWOY3qRJvzFDncIm728BNlA3ZqiHRn4cJRq96bA5mpE0exUKOy15GJTdONA21lEL9QzdZatJGb5iUAMgnKWGWM+Vrm845HC2KkChPEiB/65w2SS1KAma0+ZtbV/xhn6LJH8mUmMpCrIgPTWOAT1bC X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1615; X-MS-Office365-Filtering-Correlation-Id: 37534ed4-d836-44c2-4c42-08d327e750ac X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1615;20:ZCv6ehuVmmgmOW2gLoUN4uRQ2yCAesR++0lSQDLVG/5KwSBX2V5q1QfiPtCdEAeCShy/2r1lW0fBQT+tEuxGIzHrA870RFAuHfLBgHXivW/glh6HB2hd9v0KYyrz794DDVytOekXbIp57JCRUTrjudzahYjFmqEJfD4e4FtVNm28T7tASgMM55hm/okuCKcNoupXfIyu2JHTrQurTcanZUcW67DJFsMm3G4PFffXAz/HVUATUR/GqMzkpNNXYklD0AeJRC9rV76+4BPLfpsDj3Yjmya9bU88HLNmMfZoph9sDvIM86lYjvvIZJeuUJOAgDBhjCgtWflFsm4iaLwxKVgZc1lgrHaNUJhr2qlhbBmnM4Qz+TteXdcUaM/Q49Cv8/DzGug9IOp1KD3OyxMdA0hQyj96Q5/tpXzAKr5xYsAbKx4kxFoQkEXF/yiQJRZarYPIdF4BYPnKBmwmWYXwkOu6FrhdDaDLBk9qZ+CrFrkQeYcmXOEkKpYu8Q3ic/bcoiQ9YmFaLJGmViHr3J5i81SgJshZu6dnvvAb3qWD0GSBS+twpjxaydawztlQXYOB2FGaD9jyjvI+AL5vJgokBTMm3gqTacJO8wzZZVnNlJA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:CY1PR0701MB1615;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1615; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1615;4:2tY/x8jY7mYHpn0YLes3HXPcV1hv7oVlozAjw4Ez0NFXP1iR0sXf0sQm0nLn6YDbwQiXHRCuVkmKRB758DNCIoiPklqiAbEHPhQktE6v1hbGf6rInZXUggYHr2vdwUKJFv3tvx9ViSi1OlxhFBcRe2fWC2OME6pykyF0aDnmnQrWxx9E7pQP/ELc5OgJ9R3OTWBc/gzecCutffQAKSNvHoxfC2dTc6K2vAtIebleNg0IdKrdH3Ae5/PjjGs9F8HCQtDbAXfbbaOEqUfE/TV1ur7pzr1Fw4UhN1G+g0HHtegre1jO+49T3URFeEQ4me/YGwAoJNPKmPUnhSPrggLJaCRhjWe7IerfaZrrsoUhmUAu0JJjEBF6jqAxEWQcfI4N X-Forefront-PRVS: 083526BF8A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(199003)(24454002)(479174004)(189002)(81156007)(87976001)(47776003)(4001350100001)(97736004)(50466002)(93886004)(110136002)(19580395003)(50986999)(54356999)(76176999)(19580405001)(83506001)(97756001)(66066001)(105586002)(77096005)(5004730100002)(189998001)(86362001)(2950100001)(5001960100002)(106356001)(101416001)(5008740100001)(122386002)(33656002)(4326007)(92566002)(2906002)(23726003)(42186005)(3846002)(1076002)(1096002)(3470700001)(586003)(46406003)(6116002)(40100003);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR0701MB1615;H:rric.localdomain;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR0701MB1615;23:pQ6yUc1KsfA9cGjRrJhK8YW7zSNB9arCyq6Q/RN?= =?us-ascii?Q?1XBsS4GeqK4htGuTet2U1dUW0NW1tId2TdHs1ufg5KxDfvhv8p+VosRg1DO1?= =?us-ascii?Q?66EspLMc4ZM5oeFcPKipAv8r7a5z4bk3s7gbZEBa3wdVvgLDUe2hOjmRR4Vg?= =?us-ascii?Q?MZRyEMS8IOpPOtH9Alssuv3aLueUtKTvaUCuexLXeyTxnrr9TfUy0jStsy3E?= =?us-ascii?Q?Tc61XF1OR5PJgsw24VF/tRyUoGfk699AajqFy7xL+0SHjyNkIdZZ5PioiyIN?= =?us-ascii?Q?k6jvZ7321mZKAyKY8flx4T4wbbV+BHLVJBrpggIoxe/wMV8TbibEbky22rKQ?= =?us-ascii?Q?IoATL2rKEYjV1aFmOfBf+ODaWpI+JsYqcMbCtETrD/6KZTr3iwIYtIUxdCAM?= =?us-ascii?Q?x8t3vfgnpAkQiZY9C+C8D/6JXAAKCWIO13olzYyg5F68TyfLnSIXjCXZ9EOa?= =?us-ascii?Q?6yBC93rD7I3hZPyYlWNfrAc+KKqiUD4CmfNVViSqepS/RaTdR0VAWxlKh+4D?= =?us-ascii?Q?kZN+jqnTvId8dO/IBBdYeG0qOzuRKj6eTX3s4zwxq1lp/4N4Tl1cxgKeqxAp?= =?us-ascii?Q?ZMsMhCgW+hCECr5FhB2pe6rvGNdD4I83vSUZJJXQ42krXlwdOFA24UbX6CDK?= =?us-ascii?Q?iFotxPYE3zeaVbcD+GhYPUzJiedsjWXvbK1ICCoj1JvyLBM4nf9RZvAVza6m?= =?us-ascii?Q?SdzpklUVqq1yA0epiZYg73TnlhyTKTiglXasV3i4jMvYyPOLPMaqpMnrm2sG?= =?us-ascii?Q?N+P7BAz9NEBDZxAFpJKxnqka0PTpGLNL6sCsL7OHkRSlBsyE0dze0DxT6Qct?= =?us-ascii?Q?fnHam9R52TurlLDKWZ0s1waOfoHITltuRnVbeNXZwGWp8YzjSl8i/SoJbQpu?= =?us-ascii?Q?57RIV418vlGo8Sw/vpG9u2rSSDceVfdyQYgplqFvnHUL2LwTTGkwh3TcgT7a?= =?us-ascii?Q?LMcdQ5Q68Mr0mehtRwR7UapgVMnsJIwXXLgUjM1qjCCs7vQow5MpiAJ2YTZI?= =?us-ascii?Q?LXJnnNrrcAH49DR3oanX6eASESQMq1mL91V5Bu2wdu8s/utQDEDQIvVDqcLN?= =?us-ascii?Q?s32HFshPrFRLTk5IdnpExfB86WyJM3IFm8i2T1byop5c7kKxm8yA+nNMyehS?= =?us-ascii?Q?H7DBSxQB7Ier68ek0LeLyteg+/RiUoV/iWKkXgnRjSf2rryOpUXKBolRNgPc?= =?us-ascii?Q?cJ3Zl5ZENi3boi1A=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR0701MB1615;5:Eq6XyyWHyBhN57GqMXFrMV2AwM2HTvZK6phnC28RJuaawcBb1Un4hVzVpYLUQgUx1e64sJB5CrTM/1hdyHfaz3o/r96l8ZzYmOnNzTa5BKchbeHJmfmvTICb/b1DF9eS3x/x2nOs4vmmAiMZKASD+A==;24:2jIE2jg+F+4CMV7IWaQZpTayFxO+tkc9JizoxHRPEoGhcEDiUz6Wzrj6hzYCrwtm40XPjZDKh9363jEi75P8cisv3MUQEcVIbY82UJnCGy4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2016 13:31:20.5643 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1615 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.01.16 10:48:37, Hanjun Guo wrote: > On 2016/1/27 22:18, Robert Richter wrote: > > On 27.01.16 14:15:06, Hanjun Guo wrote: > >> Hi Robert, > >> > >> On 2016/1/25 18:26, Robert Richter wrote: > >>> On 23.01.16 17:39:27, Hanjun Guo wrote: > >>>> From: Hanjun Guo > >>>> > >>>> After the cleanup for acpi_numa_memory_affinity_init(), > >>>> it can be used for architetures both x86 and arm64, since > >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no > >>>> worry about that. > >>>> > >>>> Signed-off-by: Hanjun Guo > >>>> --- > >>>> arch/arm64/kernel/acpi_numa.c | 42 ------------------------------- > >>>> arch/x86/mm/srat.c | 54 ---------------------------------------- > >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++ > >>>> 3 files changed, 57 insertions(+), 96 deletions(-) > >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version. > >>> I rather would prefer the arm64 version for the generic code. We could > >>> keep the x86 implementation until x86 maintainers agree to remove them > >>> and use the generic one (implemented in a separate patch). > >>> > >>> Doing so we can move acpi_numa_memory_affinity_init() from the > >>> beginning to generic code (used for arm64) and have this last patch to > >>> remove the x86 version. > >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and > >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features. > >> For ARM64, firmware should be careful and represent the true platform configuration to > >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support > >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right, > >> it will be not worries for the kernel. > > But you are removing all arm64 from your first patches. Why do you > > introduce acpi_numa_memory_affinity_init() in the beginning to remove > > it in the end again? I esp. like the arm64 version because of its > > direct returns. So I still would like to see generic code for arm64 > > from the beginning. Maybe have a copy of x86 initially and make > > modifications for arm64 to it, or move missing code (hotplug, etc.) > > from x86 to generic and remove x86 arch code with the last patch. > > OK, so that's the logic and ordering of formatting the patch set, it's easy > to fix :) > > I will introduce the generic code for acpi_numa_memory_affinity_init() > in drivers/acpi/numa.c and mark it as __weak from the beginning, and > move missing code from x86 to generic, then remove x86 one as you > suggested, is that OK? Sounds good to me. Awaiting your updated version. :) Btw, I tested the whole series, so: Tested-by: Robert Richter -Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.richter@caviumnetworks.com (Robert Richter) Date: Thu, 28 Jan 2016 14:31:08 +0100 Subject: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init() In-Reply-To: <56A98185.4080202@huawei.com> References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com> <1453541967-3744-13-git-send-email-guohanjun@huawei.com> <20160125102643.GF24726@rric.localdomain> <56A8606A.8080407@huawei.com> <20160127141847.GR24726@rric.localdomain> <56A98185.4080202@huawei.com> Message-ID: <20160128133108.GY24726@rric.localdomain> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 28.01.16 10:48:37, Hanjun Guo wrote: > On 2016/1/27 22:18, Robert Richter wrote: > > On 27.01.16 14:15:06, Hanjun Guo wrote: > >> Hi Robert, > >> > >> On 2016/1/25 18:26, Robert Richter wrote: > >>> On 23.01.16 17:39:27, Hanjun Guo wrote: > >>>> From: Hanjun Guo > >>>> > >>>> After the cleanup for acpi_numa_memory_affinity_init(), > >>>> it can be used for architetures both x86 and arm64, since > >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no > >>>> worry about that. > >>>> > >>>> Signed-off-by: Hanjun Guo > >>>> --- > >>>> arch/arm64/kernel/acpi_numa.c | 42 ------------------------------- > >>>> arch/x86/mm/srat.c | 54 ---------------------------------------- > >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++ > >>>> 3 files changed, 57 insertions(+), 96 deletions(-) > >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version. > >>> I rather would prefer the arm64 version for the generic code. We could > >>> keep the x86 implementation until x86 maintainers agree to remove them > >>> and use the generic one (implemented in a separate patch). > >>> > >>> Doing so we can move acpi_numa_memory_affinity_init() from the > >>> beginning to generic code (used for arm64) and have this last patch to > >>> remove the x86 version. > >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and > >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features. > >> For ARM64, firmware should be careful and represent the true platform configuration to > >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support > >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right, > >> it will be not worries for the kernel. > > But you are removing all arm64 from your first patches. Why do you > > introduce acpi_numa_memory_affinity_init() in the beginning to remove > > it in the end again? I esp. like the arm64 version because of its > > direct returns. So I still would like to see generic code for arm64 > > from the beginning. Maybe have a copy of x86 initially and make > > modifications for arm64 to it, or move missing code (hotplug, etc.) > > from x86 to generic and remove x86 arch code with the last patch. > > OK, so that's the logic and ordering of formatting the patch set, it's easy > to fix :) > > I will introduce the generic code for acpi_numa_memory_affinity_init() > in drivers/acpi/numa.c and mark it as __weak from the beginning, and > move missing code from x86 to generic, then remove x86 one as you > suggested, is that OK? Sounds good to me. Awaiting your updated version. :) Btw, I tested the whole series, so: Tested-by: Robert Richter -Robert