[{"id":1755108,"web_url":"http://patchwork.ozlabs.org/comment/1755108/","msgid":"<87efs2y0ii.fsf@concordia.ellerman.id.au>","date":"2017-08-23T11:41:25","subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Michael Bringmann writes:\n\n> powerpc/numa: Correct the currently broken capability to set the\n> topology for shared CPUs in LPARs. At boot time for shared CPU\n> lpars, the topology for each shared CPU is set to node zero, however,\n> this is now updated correctly using the Virtual Processor Home Node\n> (VPHN) capabilities information provided by the pHyp.\n>\n> Also, update initialization checks for device-tree attributes to\n> independently recognize PRRN or VPHN usage.\n\nDid you ever do anything to address Nathan's comments on v4 ?\n\n http://patchwork.ozlabs.org/patch/767587/\n\n\nAlso your change log doesn't describe anything about what the patch does\nand why it is the correct fix for the problem.\n\nWhen a DLPAR happens you modify the VPHN timer to run in 1 nsec, but you\ndon't wait for it. Why would we not just run the logic synchronously?\n\nIt also seems to make VPHN and PRRN no longer exclusive, which looking\nat PAPR seems like it might be correct, but is also a major change so\nplease justify it in detail.\n\nComments below.\n\n\n> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c\n> index b95c584..3fd4536 100644\n> --- a/arch/powerpc/mm/numa.c\n> +++ b/arch/powerpc/mm/numa.c\n> @@ -906,7 +907,7 @@ void __init initmem_init(void)\n> \n> \t/*\n> \t * Reduce the possible NUMA nodes to the online NUMA nodes,\n> -\t * since we do not support node hotplug. This ensures that we\n> +\t * since we do not support node hotplug. This ensures that we\n\nPlease do whitespace/spelling changes in a separate patch.\n\n> \t * lower the maximum NUMA node ID to what is actually present.\n> \t */\n> \tnodes_and(node_possible_map, node_possible_map, node_online_map);\n> @@ -1148,11 +1149,32 @@ struct topology_update_data {\n> \tint new_nid;\n> };\n> \n> +#define\tTOPOLOGY_DEF_TIMER_SECS\t\t60\n> +\n> static u8 vphn_cpu_change_counts[NR_CPUS][MAX_DISTANCE_REF_POINTS];\n> static cpumask_t cpu_associativity_changes_mask;\n> static int vphn_enabled;\n> static int prrn_enabled;\n> static void reset_topology_timer(void);\n> +static int topology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;\n> +static int topology_inited;\n> +static int topology_update_needed;\n\nNone of this code should be in numa.c. Which is not your fault but I'm\ninclined to move it before we make it worse.\n\n> +\n> +/*\n> + * Change polling interval for associativity changes.\n> + */\n> +int timed_topology_update(int nsecs)\n> +{\n> +\tif (nsecs > 0)\n> +\t\ttopology_timer_secs = nsecs;\n> +\telse\n> +\t\ttopology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;\n> +\n> +\tif (vphn_enabled)\n> +\t\treset_topology_timer();\n> +\n> +\treturn 0;\n> +}\n> \n> /*\n> * Store the current values of the associativity change counters in the\n> @@ -1246,6 +1268,12 @@ static long vphn_get_associativity(unsigned long cpu,\n> \t\t\t\"hcall_vphn() experienced a hardware fault \"\n> \t\t\t\"preventing VPHN. Disabling polling...\\n\");\n> \t\tstop_topology_update();\n> +\t\tbreak;\n> +\tcase H_SUCCESS:\n> +\t\tprintk(KERN_INFO\n> +\t\t\t\"VPHN hcall succeeded. Reset polling...\\n\");\n\nWe don't need that to hit everyone's console once a minute. Remove it or\npr_debug() if you like.\n\n> @@ -1363,6 +1394,8 @@ int numa_update_cpu_topology(bool cpus_locked)\n> \t\t\tcpumask_andnot(&cpu_associativity_changes_mask,\n> \t\t\t\t\t&cpu_associativity_changes_mask,\n> \t\t\t\t\tcpu_sibling_mask(cpu));\n> +\t\t\tpr_info(\"Assoc chg gives same node %d for cpu%d\\n\",\n> +\t\t\t\t\tnew_nid, cpu);\n\nNo thanks.\n\n> @@ -1379,6 +1412,9 @@ int numa_update_cpu_topology(bool cpus_locked)\n> \t\tcpu = cpu_last_thread_sibling(cpu);\n> \t}\n> \n> +\tif (i)\n> +\t\tupdates[i-1].next = NULL;\n\n???\n\n> @@ -1453,6 +1490,14 @@ static void topology_schedule_update(void)\n> \tschedule_work(&topology_work);\n> }\n> \n> +void shared_topology_update(void)\n> +{\n> +\tif (firmware_has_feature(FW_FEATURE_VPHN) &&\n> +\t\t lppaca_shared_proc(get_lppaca()))\n> +\t\ttopology_schedule_update();\n> +}\n> +EXPORT_SYMBOL(shared_topology_update);\n\nThere's no reason for that to be exported AFAICS.\n\n> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c\n> index 3918769..ba9a4a0 100644\n> --- a/arch/powerpc/platforms/pseries/dlpar.c\n> +++ b/arch/powerpc/platforms/pseries/dlpar.c\n> @@ -592,6 +592,8 @@ static ssize_t dlpar_show(struct class *class, struct class_attribute *attr,\n> \n> static int __init pseries_dlpar_init(void)\n> {\n> +\tshared_topology_update();\n> +\n\nI don't see any reason to call that from here.\n\nIt could just as easily be a machine init call in the file where it lives.\n\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xclsM6m3kz9ryv\n\tfor ;\n\tWed, 23 Aug 2017 21:42:31 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xclsM5whWzDrR2\n\tfor ;\n\tWed, 23 Aug 2017 21:42:31 +1000 (AEST)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xclr66YjczDrJg\n\tfor ;\n\tWed, 23 Aug 2017 21:41:26 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3xclr64C1nz9sCZ;\n\tWed, 23 Aug 2017 21:41:26 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Michael Bringmann , linuxppc-dev@lists.ozlabs.org,\n\tlinux-kernel@vger.kernel.org","Subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","In-Reply-To":"<9a2f448d-0a5d-95e7-5ec1-b7bac1cb1f75@linux.vnet.ibm.com>","References":"<9a2f448d-0a5d-95e7-5ec1-b7bac1cb1f75@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Wed, 23 Aug 2017 21:41:25 +1000","Message-ID":"<87efs2y0ii.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Nathan Fontenot ,\n\tMichael Bringmann ,\n\tJohn Allen ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1755319,"web_url":"http://patchwork.ozlabs.org/comment/1755319/","msgid":"<98ae0ab7-5c46-c9a5-d927-109338fa8826@linux.vnet.ibm.com>","date":"2017-08-23T14:36:23","subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","submitter":{"id":17146,"url":"http://patchwork.ozlabs.org/api/people/17146/","name":"Nathan Fontenot","email":"nfont@linux.vnet.ibm.com"},"content":"On 08/23/2017 06:41 AM, Michael Ellerman wrote:\n> Michael Bringmann writes:\n> \n>> powerpc/numa: Correct the currently broken capability to set the\n>> topology for shared CPUs in LPARs. At boot time for shared CPU\n>> lpars, the topology for each shared CPU is set to node zero, however,\n>> this is now updated correctly using the Virtual Processor Home Node\n>> (VPHN) capabilities information provided by the pHyp.\n>>\n>> Also, update initialization checks for device-tree attributes to\n>> independently recognize PRRN or VPHN usage.\n> \n> Did you ever do anything to address Nathan's comments on v4 ?\n> \n> http://patchwork.ozlabs.org/patch/767587/\n\nLooking at this patch I do not see that VPHN is always enabled.\n\n> \n> \n> Also your change log doesn't describe anything about what the patch does\n> and why it is the correct fix for the problem.\n> \n> When a DLPAR happens you modify the VPHN timer to run in 1 nsec, but you\n> don't wait for it. Why would we not just run the logic synchronously?\n> \n> It also seems to make VPHN and PRRN no longer exclusive, which looking\n> at PAPR seems like it might be correct, but is also a major change so\n> please justify it in detail.\n\nThis is correct, they are not exclusive. When we first added PRRN support\nwe mistakenly thought they were exclusive which is why the code currently\nonly starts PRRN, or VPHN if PRRN is not present.\n\n> \n> Comments below.\n> \n> \n>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c\n>> index b95c584..3fd4536 100644\n>> --- a/arch/powerpc/mm/numa.c\n>> +++ b/arch/powerpc/mm/numa.c\n>> @@ -906,7 +907,7 @@ void __init initmem_init(void)\n>> \n>> \t/*\n>> \t * Reduce the possible NUMA nodes to the online NUMA nodes,\n>> -\t * since we do not support node hotplug. This ensures that we\n>> +\t * since we do not support node hotplug. This ensures that we\n> \n> Please do whitespace/spelling changes in a separate patch.\n> \n>> \t * lower the maximum NUMA node ID to what is actually present.\n>> \t */\n>> \tnodes_and(node_possible_map, node_possible_map, node_online_map);\n>> @@ -1148,11 +1149,32 @@ struct topology_update_data {\n>> \tint new_nid;\n>> };\n>> \n>> +#define\tTOPOLOGY_DEF_TIMER_SECS\t\t60\n>> +\n>> static u8 vphn_cpu_change_counts[NR_CPUS][MAX_DISTANCE_REF_POINTS];\n>> static cpumask_t cpu_associativity_changes_mask;\n>> static int vphn_enabled;\n>> static int prrn_enabled;\n>> static void reset_topology_timer(void);\n>> +static int topology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;\n>> +static int topology_inited;\n>> +static int topology_update_needed;\n> \n> None of this code should be in numa.c. Which is not your fault but I'm\n> inclined to move it before we make it worse.\n\nAgreed. Perhaps this should all be in mm/vphn.c\n\n-Nathan\n\n> \n>> +\n>> +/*\n>> + * Change polling interval for associativity changes.\n>> + */\n>> +int timed_topology_update(int nsecs)\n>> +{\n>> +\tif (nsecs > 0)\n>> +\t\ttopology_timer_secs = nsecs;\n>> +\telse\n>> +\t\ttopology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;\n>> +\n>> +\tif (vphn_enabled)\n>> +\t\treset_topology_timer();\n>> +\n>> +\treturn 0;\n>> +}\n>> \n>> /*\n>> * Store the current values of the associativity change counters in the\n>> @@ -1246,6 +1268,12 @@ static long vphn_get_associativity(unsigned long cpu,\n>> \t\t\t\"hcall_vphn() experienced a hardware fault \"\n>> \t\t\t\"preventing VPHN. Disabling polling...\\n\");\n>> \t\tstop_topology_update();\n>> +\t\tbreak;\n>> +\tcase H_SUCCESS:\n>> +\t\tprintk(KERN_INFO\n>> +\t\t\t\"VPHN hcall succeeded. Reset polling...\\n\");\n> \n> We don't need that to hit everyone's console once a minute. Remove it or\n> pr_debug() if you like.\n> \n>> @@ -1363,6 +1394,8 @@ int numa_update_cpu_topology(bool cpus_locked)\n>> \t\t\tcpumask_andnot(&cpu_associativity_changes_mask,\n>> \t\t\t\t\t&cpu_associativity_changes_mask,\n>> \t\t\t\t\tcpu_sibling_mask(cpu));\n>> +\t\t\tpr_info(\"Assoc chg gives same node %d for cpu%d\\n\",\n>> +\t\t\t\t\tnew_nid, cpu);\n> \n> No thanks.\n> \n>> @@ -1379,6 +1412,9 @@ int numa_update_cpu_topology(bool cpus_locked)\n>> \t\tcpu = cpu_last_thread_sibling(cpu);\n>> \t}\n>> \n>> +\tif (i)\n>> +\t\tupdates[i-1].next = NULL;\n> \n> ???\n> \n>> @@ -1453,6 +1490,14 @@ static void topology_schedule_update(void)\n>> \tschedule_work(&topology_work);\n>> }\n>> \n>> +void shared_topology_update(void)\n>> +{\n>> +\tif (firmware_has_feature(FW_FEATURE_VPHN) &&\n>> +\t\t lppaca_shared_proc(get_lppaca()))\n>> +\t\ttopology_schedule_update();\n>> +}\n>> +EXPORT_SYMBOL(shared_topology_update);\n> \n> There's no reason for that to be exported AFAICS.\n> \n>> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c\n>> index 3918769..ba9a4a0 100644\n>> --- a/arch/powerpc/platforms/pseries/dlpar.c\n>> +++ b/arch/powerpc/platforms/pseries/dlpar.c\n>> @@ -592,6 +592,8 @@ static ssize_t dlpar_show(struct class *class, struct class_attribute *attr,\n>> \n>> static int __init pseries_dlpar_init(void)\n>> {\n>> +\tshared_topology_update();\n>> +\n> \n> I don't see any reason to call that from here.\n> \n> It could just as easily be a machine init call in the file where it lives.\n> \n> \n> cheers\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xcqlP6ctbz9s4q\n\tfor ;\n\tThu, 24 Aug 2017 00:37:37 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xcqlP5dV7zDrL7\n\tfor ;\n\tThu, 24 Aug 2017 00:37:37 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xcqk51ZygzDqZv\n\tfor ;\n\tThu, 24 Aug 2017 00:36:29 +1000 (AEST)","from pps.filterd (m0098399.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7NEZ5qh001283\n\tfor ; Wed, 23 Aug 2017 10:36:27 -0400","from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2ch8hqwgey-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 23 Aug 2017 10:36:26 -0400","from localhost\n\tby e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ; \n\tWed, 23 Aug 2017 08:36:26 -0600","from b03cxnp07029.gho.boulder.ibm.com (9.17.130.16)\n\tby e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 23 Aug 2017 08:36:24 -0600","from b03ledav003.gho.boulder.ibm.com\n\t(b03ledav003.gho.boulder.ibm.com [9.17.130.234])\n\tby b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v7NEaNP18978784; Wed, 23 Aug 2017 07:36:23 -0700","from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 55DBC6A041;\n\tWed, 23 Aug 2017 08:36:23 -0600 (MDT)","from [9.41.92.186] (unknown [9.41.92.186])\n\tby b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP id F21106A043;\n\tWed, 23 Aug 2017 08:36:22 -0600 (MDT)"],"Subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","To":"Michael Ellerman ,\n\tMichael Bringmann ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org","References":"<9a2f448d-0a5d-95e7-5ec1-b7bac1cb1f75@linux.vnet.ibm.com>\n\t<87efs2y0ii.fsf@concordia.ellerman.id.au>","From":"Nathan Fontenot ","Date":"Wed, 23 Aug 2017 09:36:23 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<87efs2y0ii.fsf@concordia.ellerman.id.au>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17082314-0020-0000-0000-00000C9A7D66","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007597; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000224; SDB=6.00906515; UDB=6.00454363;\n\tIPR=6.00686717; \n\tBA=6.00005550; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016830;\n\tXFM=3.00000015; UTC=2017-08-23 14:36:25","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17082314-0021-0000-0000-00005DD6D52F","Message-Id":"<98ae0ab7-5c46-c9a5-d927-109338fa8826@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-08-23_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1708230218","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"John Allen ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1756240,"web_url":"http://patchwork.ozlabs.org/comment/1756240/","msgid":"<87y3q9utd6.fsf@concordia.ellerman.id.au>","date":"2017-08-24T10:56:21","subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Nathan Fontenot writes:\n\n> On 08/23/2017 06:41 AM, Michael Ellerman wrote:\n>> Michael Bringmann writes:\n>> \n>>> powerpc/numa: Correct the currently broken capability to set the\n>>> topology for shared CPUs in LPARs. At boot time for shared CPU\n>>> lpars, the topology for each shared CPU is set to node zero, however,\n>>> this is now updated correctly using the Virtual Processor Home Node\n>>> (VPHN) capabilities information provided by the pHyp.\n>>>\n>>> Also, update initialization checks for device-tree attributes to\n>>> independently recognize PRRN or VPHN usage.\n>> \n>> Did you ever do anything to address Nathan's comments on v4 ?\n>> \n>> http://patchwork.ozlabs.org/patch/767587/\n>\n> Looking at this patch I do not see that VPHN is always enabled.\n\nYou mean *this* patch? Or v4?\n\nI think you mean this patch, in which case I agree.\n\n>> Also your change log doesn't describe anything about what the patch does\n>> and why it is the correct fix for the problem.\n>> \n>> When a DLPAR happens you modify the VPHN timer to run in 1 nsec, but you\n>> don't wait for it. Why would we not just run the logic synchronously?\n>> \n>> It also seems to make VPHN and PRRN no longer exclusive, which looking\n>> at PAPR seems like it might be correct, but is also a major change so\n>> please justify it in detail.\n>\n> This is correct, they are not exclusive. When we first added PRRN support\n> we mistakenly thought they were exclusive which is why the code currently\n> only starts PRRN, or VPHN if PRRN is not present.\n\nOK.\n\nSo we need a patch that does that and only that, and clearly explains\nwhy we're doing that and why it's the correct thing to do.\n\nThen a 2nd patch can fiddle with the timer, if we must.\n\n...\n>>> +static int topology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;\n>>> +static int topology_inited;\n>>> +static int topology_update_needed;\n>> \n>> None of this code should be in numa.c. Which is not your fault but I'm\n>> inclined to move it before we make it worse.\n>\n> Agreed. Perhaps this should all be in mm/vphn.c\n\nActually I was thinking platforms/pseries/vphn.c\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xdLpr6MYNz9s65\n\tfor ;\n\tThu, 24 Aug 2017 20:57:24 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xdLpr5XszzDrKG\n\tfor ;\n\tThu, 24 Aug 2017 20:57:24 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xdLnf31zMzDqMc\n\tfor ;\n\tThu, 24 Aug 2017 20:56:22 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3xdLnd75Q9z9sPk;\n\tThu, 24 Aug 2017 20:56:21 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Nathan Fontenot ,\n\tMichael Bringmann ,\n\tlinuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN\n\tenabled","In-Reply-To":"<98ae0ab7-5c46-c9a5-d927-109338fa8826@linux.vnet.ibm.com>","References":"<9a2f448d-0a5d-95e7-5ec1-b7bac1cb1f75@linux.vnet.ibm.com>\n\t<87efs2y0ii.fsf@concordia.ellerman.id.au>\n\t<98ae0ab7-5c46-c9a5-d927-109338fa8826@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Thu, 24 Aug 2017 20:56:21 +1000","Message-ID":"<87y3q9utd6.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"John Allen ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]