public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Waiman Long <longman@redhat.com>, "Zhang\,
	Qiang" <Qiang.Zhang@windriver.com>,
	"elver\@google.com" <elver@google.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm\@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: 回复: [PATCH] debugobjects: install cpu hotplug callback
Date: Wed, 26 Aug 2020 01:53:05 +0200	[thread overview]
Message-ID: <87pn7ewae6.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <e75c1601-b466-8476-f75b-514b1c21646e@redhat.com>

On Tue, Aug 25 2020 at 18:26, Waiman Long wrote:
> On 8/25/20 12:53 AM, Zhang, Qiang wrote:
>>
>> When a cpu going offline, we should free objects in "percpu_obj_pool"
>> free_objs list which corresponding to this cpu.
>
> The percpu free object pool is supposed to be accessed only by that 
> particular cpu without any lock. Trying to access it from another cpu 
> can cause a race condition unless one can make sure that the offline cpu 
> won't become online in the mean time. 

It is actually safe because CPU hotplug is globally serialized and there
is no way that an offline CPU will come back from death valley
magically. If such a zombie ever surfaces then we have surely more
serious problems than accessing that pool :)

> There shouldn't be too many free objects in the percpu pool. Is it
> worth the effort to free them?

That's a really good question nevertheless. The only case where this
ever matters is physical hotplug. All other CPU hotplug stuff is
temporarily or in case of a late (post boottime) SMT disable it's going
to be a handful of free objects on that pool. As debugobjects is as the
name says a debug facility the benefit is questionable unless there is a
good reason to do so.

Thanks,

        tglx



  parent reply	other threads:[~2020-08-25 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-20  3:24 [PATCH] debugobjects: install cpu hotplug callback qiang.zhang
2020-08-25  4:53 ` 回复: " Zhang, Qiang
2020-08-25 22:26   ` Waiman Long
2020-08-25 23:32     ` Waiman Long
2020-08-25 23:53     ` Thomas Gleixner [this message]
2020-08-26  0:48       ` Waiman Long
2020-08-26  8:34       ` 回复: " Zhang, Qiang
2020-08-26  9:41         ` Thomas Gleixner

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=87pn7ewae6.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=Qiang.Zhang@windriver.com \
    --cc=akpm@linux-foundation.org \
    --cc=elver@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.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