From: Ingo Molnar <mingo@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>,
akpm@linuxfoundation.org, Steven Rostedt <srostedt@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [pchecks v1 3/4] Use raw_cpu_ops for refresh_cpu_vm_stats()
Date: Tue, 24 Sep 2013 09:43:52 +0200 [thread overview]
Message-ID: <20130924074351.GF28538@gmail.com> (raw)
In-Reply-To: <000001414c47a1ab-17a7541e-54ac-4c15-8a02-66c83c358cbd-000000@email.amazonses.com>
* Christoph Lameter <cl@linux.com> wrote:
> We do not care about races for the expiration logic in
> refresh_cpu_vm_stats(). Draining is a rare act after all.
> No need to create too much overhead for that.
>
> Use raw_cpu_ops there.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
> Index: linux/mm/vmstat.c
> ===================================================================
> --- linux.orig/mm/vmstat.c 2013-09-23 10:20:31.742262228 -0500
> +++ linux/mm/vmstat.c 2013-09-23 10:20:31.738262268 -0500
> @@ -439,6 +439,10 @@ static inline void fold_diff(int *diff)
> * statistics in the remote zone struct as well as the global cachelines
> * with the global counters. These could cause remote node cache line
> * bouncing and will have to be only done when necessary.
> + *
> + * Note that we have to use raw_cpu ops here. The thread is pinned
> + * to a specific processor but the preempt checking logic does not
> + * know about this.
That's not actually true - debug_smp_processor_id() does a check for the
pinning status of the current task:
/*
* Kernel threads bound to a single CPU can safely use
* smp_processor_id():
*/
if (cpumask_equal(tsk_cpus_allowed(current), cpumask_of(this_cpu)))
goto out;
You should factor out those existing debug checks and reuse them, instead
of using inferior ones.
Note that debug_smp_processor_id() can probably be optimized a bit: today
we have p->nr_cpus_allowed which tracks the pinning status, so instead of
the above line we could write this cheaper form:
if (current->nr_cpus_allowed == 1)
goto out;
(This should help on kernels configured for larger systems where the
cpumask is non-trivial.)
What we cannot do is to hide the weakness of the debug check you added by
adding various workarounds to core code.
Thanks,
Ingo
prev parent reply other threads:[~2013-09-24 7:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130923191256.584672290@linux.com>
2013-09-23 19:12 ` [pchecks v1 2/4] Use raw cpu ops for calls that would trigger with checks Christoph Lameter
2013-09-24 7:28 ` Ingo Molnar
2013-09-24 7:32 ` Ingo Molnar
2013-09-24 12:45 ` Eric Dumazet
2013-09-24 7:34 ` Ingo Molnar
2013-09-23 19:12 ` [pchecks v1 1/4] Subject; percpu: Add raw_cpu_ops Christoph Lameter
2013-09-23 19:24 ` [pchecks v1 4/4] percpu: Add preemption checks to __this_cpu ops Christoph Lameter
2013-09-24 8:03 ` Ingo Molnar
2013-09-24 14:24 ` Christoph Lameter
2013-09-24 15:18 ` Ingo Molnar
2013-09-24 15:35 ` Christoph Lameter
2013-09-24 17:26 ` Ingo Molnar
2013-09-25 16:46 ` Christoph Lameter
2013-09-25 18:26 ` Ingo Molnar
2013-09-27 14:36 ` Christoph Lameter
2013-09-28 8:52 ` Ingo Molnar
2013-09-23 19:24 ` [pchecks v1 3/4] Use raw_cpu_ops for refresh_cpu_vm_stats() Christoph Lameter
2013-09-24 7:43 ` Ingo Molnar [this message]
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=20130924074351.GF28538@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=srostedt@redhat.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.