linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: cl@linux.com, tj@kernel.org, mika.j.penttila@gmail.com,
	mingo@redhat.com, akpm@linux-foundation.org, rjw@rjwysocki.net,
	hpa@zytor.com, yasu.isimatu@gmail.com,
	isimatu.yasuaki@jp.fujitsu.com, kamezawa.hiroyu@jp.fujitsu.com,
	izumi.taku@jp.fujitsu.com, gongzhaogang@inspur.com,
	len.brown@intel.com, lenb@kernel.org, chen.tang@easystack.cn,
	rafael@kernel.org, x86@kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Gu Zheng <guz.fnst@cn.fujitsu.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v10 2/7] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus at boot time.
Date: Fri, 29 Jul 2016 15:36:51 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1607291526210.19896@nanos> (raw)
In-Reply-To: <1469513429-25464-3-git-send-email-douly.fnst@cn.fujitsu.com>

On Tue, 26 Jul 2016, Dou Liyang wrote: 

> 1. Enable apic registeration flow to handle both enabled and disabled cpus.
>    This is done by introducing an extra parameter to generic_processor_info to
>    let the caller control if disabled cpus are ignored.

If I'm reading the patch correctly then the 'enabled' argument controls more
than the disabled cpus accounting. It also controls the modification of
num_processors and the present mask.
 
> -int generic_processor_info(int apicid, int version)
> +static int __generic_processor_info(int apicid, int version, bool enabled)
>  {
>  	int cpu, max = nr_cpu_ids;
>  	bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> @@ -2032,7 +2032,8 @@ int generic_processor_info(int apicid, int version)
>  			   " Processor %d/0x%x ignored.\n",
>  			   thiscpu, apicid);
>  
> -		disabled_cpus++;
> +		if (enabled)
> +			disabled_cpus++;
>  		return -ENODEV;
>  	}
>  
> @@ -2049,7 +2050,8 @@ int generic_processor_info(int apicid, int version)
>  			" reached. Keeping one slot for boot cpu."
>  			"  Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
>  
> -		disabled_cpus++;
> +		if (enabled)
> +			disabled_cpus++;

This is utterly confusing. That code path cannot be reached when enabled is
false, because num_processors is 0 as we never increment it when enabled is
false.

That said, I really do not like this 'slap some argument on it and make it
work somehow' approach.

The proper solution for this is to seperate out the functionality which you
need for the preparation run (enabled = false) and make sure that the
information you need for the real run (enabled = true) is properly cached
somewhere so we don't have to evaluate the same thing over and over.

Thanks,

	tglx

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-07-29 13:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26  6:10 [PATCH v10 0/7] Make cpuid <-> nodeid mapping persistent Dou Liyang
2016-07-26  6:10 ` [PATCH v10 1/7] x86, memhp, numa: Online memory-less nodes at boot time Dou Liyang
2016-07-26  6:10 ` [PATCH v10 2/7] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus " Dou Liyang
2016-07-29 13:36   ` Thomas Gleixner [this message]
2016-08-02  7:30     ` Dou Liyang
2016-07-26  6:10 ` [PATCH v10 3/7] x86, acpi, cpu-hotplug: Introduce cpuid_to_apicid[] array to store persistent cpuid <-> apicid mapping Dou Liyang
2016-07-26  6:10 ` [PATCH v10 4/7] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid Dou Liyang
2016-07-26  6:10 ` [PATCH v10 5/7] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting Dou Liyang
2016-07-26  6:10 ` [PATCH v10 6/7] acpi: Provide the mechanism to validate processors in the ACPI tables Dou Liyang
2016-07-26  6:10 ` [PATCH v10 7/7] acpi: Provide the interface to validate the proc_id Dou Liyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1607291526210.19896@nanos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=chen.tang@easystack.cn \
    --cc=cl@linux.com \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=gongzhaogang@inspur.com \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mika.j.penttila@gmail.com \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tj@kernel.org \
    --cc=x86@kernel.org \
    --cc=yasu.isimatu@gmail.com \
    --cc=zhugh.fnst@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox