From: Andi Kleen <andi@firstfloor.org>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"mingo\@elte.hu" <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jiri Olsa <jolsa@redhat.com>, "Yan\,
Zheng" <zheng.z.yan@intel.com>
Subject: Re: [PATCH v1 1/2] perf,x86: add Intel RAPL PMU support
Date: Mon, 07 Oct 2013 14:45:44 -0700 [thread overview]
Message-ID: <87pprgzref.fsf@tassilo.jf.intel.com> (raw)
In-Reply-To: <CABPqkBRYCGumFo1JO6VKXUiVpoDdUW61X7cHJeyw3WDu-wxM8Q@mail.gmail.com> (Stephane Eranian's message of "Mon, 7 Oct 2013 22:58:44 +0200")
Stephane Eranian <eranian@google.com> writes:
>
>>> + goto again;
>>> +
>>> + struct rapl_pmu *pmu = __get_cpu_var(rapl_pmu);
>>> +
>>> + if (WARN_ON_ONCE(!(event->hw.state & PERF_HES_STOPPED)))
>>> + return;
>>> +
>>> + event->hw.state = 0;
>>> +
>>> + local64_set(&event->hw.prev_count, rapl_read_counter(event));
>>> +
>>> + pmu->n_active++;
>>
>> What lock protects this add?
>>
> None. I will add one. Bu then I am wondering about if it is really
> necessary given
> that RAPL event are system-wide and this pinned to a CPU. If the call came
> from another CPU, then it IPI there, and that means that CPU is executing that
> code. Any other CPU will need IPI too, and that interrupt will be kept pending.
> Am I missing a test case here? Are IPI reentrant?
they can be if interrupts are enabled (likely here)
>
>>> +}
>>> +
>>> +static ssize_t rapl_get_attr_cpumask(struct device *dev,
>>> + struct device_attribute *attr, char *buf)
>>> +{
>>> + int n = cpulist_scnprintf(buf, PAGE_SIZE - 2, &rapl_cpu_mask);
>>
>> Check n here in case it overflowed
>>
> But isn't that what the -2 and the below \n\0 are for?
I know it's very unlikely and other stuff would break, but
Assuming you have a system with some many CPUs that they don't fit
into a page. Then the scnprintf would fail, but you would corrupt
random data because you write before the buffer.
>> Doesn't this need a lock of some form? AFAIK we can do parallel
>> CPU startup now.
>>
> Did not know about this change? But then that means all the other
> perf_event *_starting() and maybe even _*prepare() routines must also
> use locks. I can add that to RAPL.
Yes may be broken everywhere.
>>> + /* check supported CPU */
>>> + switch (boot_cpu_data.x86_model) {
>>> + case 42: /* Sandy Bridge */
>>> + case 58: /* Ivy Bridge */
>>> + case 60: /* Haswell */
>>
>> Need more model numbers for Haswell (see the main perf driver)
>>
> Don't have all the models to test...
It should be all the same.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2013-10-07 21:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 16:09 [PATCH v1 0/2] perf,x86: add Intel RAPL PMU support Stephane Eranian
2013-10-07 16:09 ` [PATCH v1 1/2] " Stephane Eranian
2013-10-07 17:55 ` Andi Kleen
2013-10-07 18:08 ` Peter Zijlstra
2013-10-07 19:22 ` Andi Kleen
2013-10-07 20:33 ` Peter Zijlstra
2013-10-08 7:36 ` Ingo Molnar
2013-10-07 20:58 ` Stephane Eranian
2013-10-07 21:45 ` Andi Kleen [this message]
2013-10-07 22:38 ` Stephane Eranian
2013-10-08 15:10 ` Stephane Eranian
2013-10-07 16:09 ` [PATCH v1 2/2] perf,x86: add RAPL hrtimer support Stephane Eranian
2013-10-07 16:19 ` [PATCH v1 0/2] perf,x86: add Intel RAPL PMU support Borislav Petkov
2013-10-07 16:24 ` Stephane Eranian
2013-10-07 16:42 ` Borislav Petkov
2013-10-07 16:29 ` Peter Zijlstra
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=87pprgzref.fsf@tassilo.jf.intel.com \
--to=andi@firstfloor.org \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--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 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.