public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: mingo@kernel.org, peterz@infradead.org, rjw@rjwysocki.net,
	hpa@zytor.com, rafael@kernel.org, cl@linux.com, tj@kernel.org,
	akpm@linux-foundation.org, rafael.j.wysocki@intel.com,
	len.brown@intel.com, izumi.taku@jp.fujitsu.com,
	xiaolong.ye@intel.com, x86@kernel.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
Date: Wed, 1 Mar 2017 11:51:04 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1703011137560.4005@nanos> (raw)
In-Reply-To: <1487580471-17665-2-git-send-email-douly.fnst@cn.fujitsu.com>

On Mon, 20 Feb 2017, Dou Liyang wrote:

> Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
> It keeps consistent with the WorkQueue and avoids some bugs which may be caused
> by the dynamic assignment.
> 
> But, The ACPI table is unreliable and it is very risky that we use the entity
> which isn't related to a physical device at booting time.
> 
> Now, we revert our patches. Do the last mapping of "cpuid <-> nodeid" at
> hot-plug time, not at booting time where we did some useless work.
> It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
> use of the ACPI table.
> 
> The patch revert the commit dc6db24d24:
>   "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting".

That changelog needs some massaging. Something like this:

  The mapping of "cpuid <-> nodeid" is established at boot time via ACPI
  tables to keep associations of workqueues and other node related items
  consistent across cpu hotplug.

  But, ACPI tables are unreliable and failures with that boot time mapping
  have been reported on machines where the ACPI table and the physical
  information which is retrieved at actual hotplug is inconsistent.

  Revert the mapping implementation so it can be replaced with a less error
  prone approach.

This clearly describes:

  1) The context

  2) The problem

  3) The solution (revert)

You don't have to explain what the new solution will be in the changelog of
the revert. For the revert it's only relevant WHY we do the revert.

Please avoid writing changelogs in 'we' form. Write it pure technical, like
a manual.

Also avoid phrases like: "The patch/This patch". We all know already that
this is a patch, otherwise it wouldn't have been sent.

Documentation/process/submitting-patches.rst says:

  Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
  instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
  to do frotz", as if you are giving orders to the codebase to change
  its behaviour.

Thanks,

	tglx

  reply	other threads:[~2017-03-01 10:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20  8:47 [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Dou Liyang
2017-02-20  8:47 ` [PATCH v2 1/4] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Dou Liyang
2017-03-01 10:51   ` Thomas Gleixner [this message]
2017-03-02  7:58     ` Dou Liyang
2017-02-20  8:47 ` [PATCH v2 2/4] Revert"x86/acpi: Enable MADT APIs to return disabled apicids" Dou Liyang
2017-03-01 10:52   ` Thomas Gleixner
2017-03-02  8:02     ` Dou Liyang
2017-02-20  8:47 ` [PATCH v2 3/4] acpi: Fix the check handle in case of declaring processors using the Device operator Dou Liyang
2017-03-01 11:12   ` Thomas Gleixner
2017-03-02  8:12     ` Dou Liyang
2017-02-20  8:47 ` [PATCH v2 4/4] acpi: Move the verification of duplicate proc_id from booting time to hot-plug time Dou Liyang
2017-03-01 11:26   ` Thomas Gleixner
2017-03-02  8:20     ` Dou Liyang
2017-02-21  1:02 ` [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Ye Xiaolong
2017-02-21  7:10   ` Ye Xiaolong
2017-02-22  1:56     ` Dou Liyang
2017-03-16  8:14       ` [LKP] " Aaron Lu
2017-03-16  8:28         ` Thomas Gleixner
2017-03-16  8:38           ` Aaron Lu

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.20.1703011137560.4005@nanos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tj@kernel.org \
    --cc=x86@kernel.org \
    --cc=xiaolong.ye@intel.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