linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"mingo@elte.hu" <mingo@elte.hu>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"Yan, Zheng" <zheng.z.yan@intel.com>,
	Robert Richter <robert.richter@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 1/3] hrtimer: add hrtimer_init_cpu()
Date: Wed, 12 Sep 2012 16:33:25 +0200	[thread overview]
Message-ID: <CABPqkBSnhjgAhn5+gOuBWWPrxKojKW1hKPJEn7zvvYhiw-LPLg@mail.gmail.com> (raw)
In-Reply-To: <1347459984.15764.34.camel@twins>

On Wed, Sep 12, 2012 at 4:26 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> I'm rather sure Thomas would want to know about this..
>
>
> On Wed, 2012-09-12 at 16:13 +0200, Stephane Eranian wrote:
>> hrtimer_init() assumes it is called for the current CPU
>> as it accesses per-cpu variables (hrtimer_bases).
>>
>> However, there can be cases where a hrtimer is initialized
>> from a different CPU, so add an entry point to make this
>> more explicit.
>>
>> Signed-off-by: Stephane Eranian <eranian@google.com>
>> ---
>>  include/linux/hrtimer.h |    3 +++
>>  kernel/hrtimer.c        |   17 ++++++++++++-----
>>  2 files changed, 15 insertions(+), 5 deletions(-)
>>
>
>> +static void __hrtimer_init(int cpu, struct hrtimer *timer, clockid_t clock_id,
>>                          enum hrtimer_mode mode)
>>  {
>>       struct hrtimer_cpu_base *cpu_base;
>> @@ -1154,7 +1154,7 @@ static void __hrtimer_init(struct hrtimer *timer, clockid_t clock_id,
>>
>>       memset(timer, 0, sizeof(struct hrtimer));
>>
>> -     cpu_base = &__raw_get_cpu_var(hrtimer_bases);
>> +     cpu_base = &per_cpu(hrtimer_bases, cpu);
>>
>>       if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)
>>               clock_id = CLOCK_MONOTONIC;
>
>
> I don't see the point, one of the first things
> __hrtimer_start_range_ns() does is switch_hrtimer_base() to swizzle it
> to the calling CPUs base.
>
> And since all the perf event rotation muck is strictly per cpu that all
> should work out just fine, no?


If I do:
  for_each_possible_cpu(cpu) {
       cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
       hr = &cpuctx->hrtimer;
       hrtimer_init(hr)
}
I don't understand why I would have to refer to per-cpu data
(hrtimer_bases) from
a CPU that is not equal to "cpu" here. Unless you're telling me it's
read-only data.
But still if it's per-cpu why not initialize with the correct CPU from
the start?

  reply	other threads:[~2012-09-12 14:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 14:13 [PATCH v2 0/3] perf: use hrtimer for event multiplexing Stephane Eranian
2012-09-12 14:13 ` [PATCH v2 1/3] hrtimer: add hrtimer_init_cpu() Stephane Eranian
2012-09-12 14:22   ` Eric Dumazet
2012-09-12 14:26   ` Peter Zijlstra
2012-09-12 14:33     ` Stephane Eranian [this message]
2012-09-12 14:38       ` Peter Zijlstra
2012-09-12 14:46         ` Stephane Eranian
2012-09-12 14:49           ` Peter Zijlstra
2012-09-12 14:51             ` Stephane Eranian
2012-09-12 14:13 ` [PATCH v2 2/3] perf: use hrtimer for event multiplexing Stephane Eranian
2012-09-12 14:22   ` Peter Zijlstra
2012-09-12 14:43     ` Stephane Eranian
2012-09-12 14:44       ` Peter Zijlstra
2012-09-12 14:48         ` Stephane Eranian
2012-09-12 14:50           ` Peter Zijlstra
2012-09-12 15:37       ` Stephane Eranian
2012-09-12 15:49         ` Stephane Eranian
2012-09-13 12:16         ` Peter Zijlstra
2012-09-13 12:20           ` Stephane Eranian
2012-09-13 12:26             ` Peter Zijlstra
2012-09-13 12:27               ` Stephane Eranian
2012-09-13 12:29                 ` Peter Zijlstra
2012-09-12 14:13 ` [PATCH v2 3/3] perf: add sysfs entry to adjust multiplexing interval per PMU Stephane Eranian

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=CABPqkBSnhjgAhn5+gOuBWWPrxKojKW1hKPJEn7zvvYhiw-LPLg@mail.gmail.com \
    --to=eranian@google.com \
    --cc=ak@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    --cc=zheng.z.yan@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;
as well as URLs for NNTP newsgroup(s).