From: Peter Zijlstra <peterz@infradead.org>
To: "Yan, Zheng" <zheng.z.yan@intel.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
eranian@google.com, andi@firstfloor.org
Subject: Re: [PATCH v2 3/7] perf, x86: Introduce x86 special perf event context
Date: Thu, 4 Jul 2013 14:41:48 +0200 [thread overview]
Message-ID: <20130704124148.GI23916@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1372663387-11754-4-git-send-email-zheng.z.yan@intel.com>
On Mon, Jul 01, 2013 at 03:23:03PM +0800, Yan, Zheng wrote:
> From: "Yan, Zheng" <zheng.z.yan@intel.com>
>
> The x86 special perf event context is named x86_perf_event_context,
> We can enlarge it later to store PMU special data.
This changelog is completely inadequate. It fails to state what and why
we do things.
I hate doing this; but I can't see another way around it either. That
said:
> @@ -274,6 +274,11 @@ struct pmu {
> * flush branch stack on context-switches (needed in cpu-wide mode)
> */
> void (*flush_branch_stack) (void);
> +
> + /*
> + * Allocate PMU special perf event context
> + */
> + void *(*event_context_alloc) (struct perf_event_context *parent_ctx);
> };
It should be *optional*, also wtf is that parent_ctx thing for?
> +++ b/kernel/events/core.c
> @@ -2961,13 +2961,20 @@ static void __perf_event_init_context(struct perf_event_context *ctx)
> }
>
> static struct perf_event_context *
> -alloc_perf_context(struct pmu *pmu, struct task_struct *task)
> +alloc_perf_context(struct pmu *pmu, struct task_struct *task,
> + struct perf_event_context *parent_ctx)
> {
> struct perf_event_context *ctx;
>
> - ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
> - if (!ctx)
> - return NULL;
> + if (pmu->event_context_alloc) {
> + ctx = pmu->event_context_alloc(parent_ctx);
> + if (IS_ERR(ctx))
> + return ctx;
> + } else {
> + ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
> + if (!ctx)
> + return ERR_PTR(-ENOMEM);
> + }
>
> __perf_event_init_context(ctx);
> if (task) {
I'm not at all sure we want to do it like this; why not simply query the
size. Something like:
alloc_perf_context(struct pmu *pmu, struct task_struct *task)
{
size_t ctx_size = sizeof(struct perf_event_context);
if (pmu->task_context_size)
size = pmu->task_context_size();
ctx = kzalloc(size, GFP_KERNEL);
if (!ctx)
return ERR_PTR(-ENOMEM);
...
}
next prev parent reply other threads:[~2013-07-04 12:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 7:23 [PATCH v2 0/7] perf, x86: Haswell LBR call stack support Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 1/7] perf, x86: Reduce lbr_sel_map size Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 2/7] perf, x86: Basic Haswell LBR call stack support Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 3/7] perf, x86: Introduce x86 special perf event context Yan, Zheng
2013-07-04 12:41 ` Peter Zijlstra [this message]
2013-07-05 3:19 ` Yan, Zheng
2013-07-05 12:45 ` Peter Zijlstra
2013-07-08 8:51 ` Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 4/7] perf, x86: Save/resotre LBR stack during context switch Yan, Zheng
2013-07-04 9:57 ` Peter Zijlstra
2013-07-04 11:39 ` Yan, Zheng
2013-07-04 13:44 ` Andi Kleen
2013-07-04 14:00 ` Peter Zijlstra
2013-07-10 17:57 ` Andi Kleen
2013-07-04 12:44 ` Peter Zijlstra
2013-07-04 12:45 ` Peter Zijlstra
2013-07-05 5:36 ` Yan, Zheng
2013-07-05 8:15 ` Peter Zijlstra
2013-07-05 8:51 ` Yan, Zheng
2013-07-05 12:31 ` Peter Zijlstra
2013-08-08 6:18 ` Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 5/7] perf, core: Pass perf_sample_data to perf_callchain() Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 6/7] perf, x86: Use LBR call stack to get user callchain Yan, Zheng
2013-07-01 7:23 ` [PATCH v2 7/7] perf, x86: Discard zero length call entries in LBR call stack Yan, Zheng
-- strict thread matches above, loose matches on Subject: below --
2012-10-24 5:59 [PATCH V2 0/7] perf, x86: Haswell LBR call stack support Yan, Zheng
2012-10-24 5:59 ` [PATCH V2 3/7] perf, x86: Introduce x86 special perf event context Yan, Zheng
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=20130704124148.GI23916@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox