All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Vince Weaver <vincent.weaver@maine.edu>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	trinity@vger.kernel.org, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH 2/2] hw_breakpoint: Introduce "struct bp_cpuinfo"
Date: Tue, 18 Jun 2013 16:42:25 +0200	[thread overview]
Message-ID: <20130618144225.GA26920@redhat.com> (raw)
In-Reply-To: <20130618123741.GC17619@somewhere.redhat.com>

On 06/18, Frederic Weisbecker wrote:
>
> On Sun, Jun 02, 2013 at 09:50:57PM +0200, Oleg Nesterov wrote:
> > This patch simply moves all per-cpu variables into the new single
> > per-cpu "struct bp_cpuinfo".
> >
> > To me this looks more logical and clean, but this can also simplify
> > the further potential changes. In particular, I do not think this
> > memory should be per-cpu, it is never used "locally". After this
> > change it is trivial to turn it into, say, bootmem[nr_cpu_ids].
> >
> > Signed-off-by: Oleg Nesterov <oleg@redhat.com>
>
> I'm ok with the patch because it's indeed more logical and clean to pack the info
> to a single struct.

Great,

> But I'm not sure why you think using per-cpu is a problem. It's not only
> deemed for optimized local uses,

But it is.

Simplest example,

	for_each_possible_cpu(cpu)
		total_count = per_cpu(per_cpu_count, cpu);

Every per_cpu() likely means the cache miss. Not to mention we need the
additional math to calculate the address of the local counter.

	for_each_possible_cpu(cpu)
		total_count = bootmem_or_kmalloc_array[cpu];

is much better in this respect.

And note also that per_cpu_count above can share the cacheline with
another "hot" per-cpu variable.

> it's also convenient for allocations and
> de-allocation, or static definitions.

Yes, this is advantage. But afaics the only one.

> I'm not sure why bootmem would make
> more sense.

Or kcalloc(nr_cpu_ids), I didn't really mean that alloc_bootmem() is
necessarily the best option.

> Other than this in the changelog, the patch is nice, thanks!
>
> Acked-by: Frederic Weisbecker <fweisbec@gmail.com>

Thanks ;)

Oleg.

  reply	other threads:[~2013-06-18 14:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 16:19 WARN_ONCE in arch/x86/kernel/hw_breakpoint.c Vince Weaver
2013-05-28 17:00 ` Oleg Nesterov
2013-05-28 17:28   ` Oleg Nesterov
2013-05-28 18:47     ` Oleg Nesterov
2013-05-29 16:32       ` [MAYBEPATCH] : " Oleg Nesterov
2013-06-01 18:20 ` [PATCH 0/2]: " Oleg Nesterov
2013-06-01 18:21   ` [PATCH 1/2] hw_breakpoint: Fix cpu check in task_bp_pinned(cpu) Oleg Nesterov
2013-06-13 14:20     ` Frederic Weisbecker
2013-06-01 18:21   ` [PATCH 2/2] hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot() Oleg Nesterov
2013-06-15 12:46     ` Frederic Weisbecker
2013-06-01 19:45 ` [PATCH 0/3] hw_breakpoint: cleanups Oleg Nesterov
2013-06-01 19:45   ` [PATCH 1/3] hw_breakpoint: Simplify list/idx mess in toggle_bp_slot() paths Oleg Nesterov
2013-06-15 12:59     ` Frederic Weisbecker
2013-06-01 19:46   ` [PATCH 2/3] hw_breakpoint: Simplify the "weight" usage " Oleg Nesterov
2013-06-15 13:14     ` Frederic Weisbecker
2013-06-01 19:46   ` [PATCH 3/3] hw_breakpoint: Introduce cpumask_of_bp() Oleg Nesterov
2013-06-15 13:29     ` Frederic Weisbecker
2013-06-13 14:01   ` [PATCH 0/3] hw_breakpoint: cleanups Frederic Weisbecker
2013-06-13 15:15     ` Oleg Nesterov
2013-06-13 15:24       ` Frederic Weisbecker
2013-06-02 19:49 ` [PATCH 0/2] hw_breakpoint: more cleanups Oleg Nesterov
2013-06-02 19:50   ` [PATCH 1/2] hw_breakpoint: Simplify *register_wide_hw_breakpoint() Oleg Nesterov
2013-06-18  0:12     ` Frederic Weisbecker
2013-06-02 19:50   ` [PATCH 2/2] hw_breakpoint: Introduce "struct bp_cpuinfo" Oleg Nesterov
2013-06-18 12:37     ` Frederic Weisbecker
2013-06-18 14:42       ` Oleg Nesterov [this message]
2013-06-18 17:01         ` Frederic Weisbecker
2013-06-19 15:54           ` Oleg Nesterov

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=20130618144225.GA26920@redhat.com \
    --to=oleg@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=trinity@vger.kernel.org \
    --cc=vincent.weaver@maine.edu \
    /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.