From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, tglx@linutronix.de, bp@alien8.de,
acme@kernel.org, namhyung@kernel.org, irogers@google.com,
linux-kernel@vger.kernel.org, ak@linux.intel.com,
eranian@google.com
Subject: Re: [PATCH V8 1/6] perf: Save PMU specific data in task_struct
Date: Wed, 12 Mar 2025 15:41:06 -0400 [thread overview]
Message-ID: <702802d2-7318-4575-81ac-4fad6f8ff42f@linux.intel.com> (raw)
In-Reply-To: <20250312190533.GA10453@noisy.programming.kicks-ass.net>
On 2025-03-12 3:05 p.m., Peter Zijlstra wrote:
>
> I'm sorry, but since I spotted a bug in the second patch, I'm going to
> reply and suggest some overall changes.
Sure. Thanks.
>
> On Wed, Mar 12, 2025 at 11:25:20AM -0700, kan.liang@linux.intel.com wrote:
>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 3e270822b915..b8442047a2b6 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -1021,6 +1021,36 @@ struct perf_event_context {
>> local_t nr_no_switch_fast;
>> };
>>
>> +/**
>> + * struct perf_ctx_data - PMU specific data for a task
>> + * @rcu_head: To avoid the race on free PMU specific data
>> + * @refcount: To track users
>> + * @global: To track system-wide users
>> + * @ctx_cache: Kmem cache of PMU specific data
>> + * @data: PMU specific data
>> + *
>> + * Currently, the struct is only used in Intel LBR call stack mode to
>> + * save/restore the call stack of a task on context switches.
>> + * The data only be allocated when Intel LBR call stack mode is enabled.
>> + * The data will be freed when the mode is disabled. The rcu_head is
>> + * used to prevent the race on free the data.
>> + * The content of the data will only be accessed in context switch, which
>> + * should be protected by rcu_read_lock().
>> + *
>> + * Careful: Struct perf_ctx_data is added as a pointor in struct task_struct.
>
> pointer
>
>> + * When system-wide Intel LBR call stack mode is enabled, a buffer with
>> + * constant size will be allocated for each task.
>> + * Also, system memory consumption can further grow when the size of
>> + * struct perf_ctx_data enlarges.
>> + */
>> +struct perf_ctx_data {
>> + struct rcu_head rcu_head;
>> + refcount_t refcount;
>> + int global;
>> + struct kmem_cache *ctx_cache;
>> + void *data;
>> +};
>
> I can't remember why this is complicated like this. Why do we have a
> kmemcache and yet another data pointer in there?
The kmem_cache is introduced to address the alignment requirement for
Arch LBR.
https://lore.kernel.org/lkml/159420190705.4006.11190540790919295173.tip-bot2@tip-bot2/
When users do system-wide profiling, perf has to allocate a buffer when
forking a thread or delete a buffer when deleting a thread. The
pmu->task_ctx_cache is required. Perf has to search the perf_event_list
every time to find the proper PMU.
So the *ctx_cache is introduced to avoid the search.
Thanks,
Kan
>
> Specifically, why can't we do something like:
>
> struct perf_ctx_data {
> struct rcu_head rcu;
> refcount_t refcount;
> int global;
> char data[];
> };
>
> and simply allocate the whole thing as a single allocation?
>
> So then the allocation is something like:
>
> cd = kzalloc(sizeof(*cd) + event->pmu->task_ctx_size, GFP_KERNEL);
>
>
next prev parent reply other threads:[~2025-03-12 19:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 18:25 [PATCH V8 1/6] perf: Save PMU specific data in task_struct kan.liang
2025-03-12 18:25 ` [PATCH V8 2/6] perf: attach/detach PMU specific data kan.liang
2025-03-12 19:18 ` Peter Zijlstra
2025-03-12 19:52 ` Liang, Kan
2025-03-12 23:23 ` kernel test robot
2025-03-12 23:46 ` kernel test robot
2025-03-13 15:09 ` Nathan Chancellor
2025-03-13 23:06 ` Philip Li
2025-03-12 18:25 ` [PATCH V8 3/6] perf: Supply task information to sched_task() kan.liang
2025-03-13 4:32 ` kernel test robot
2025-03-12 18:25 ` [PATCH V8 4/6] perf/x86/lbr: Fix shorter LBRs call stacks for the system-wide mode kan.liang
2025-03-12 18:25 ` [PATCH V8 5/6] perf/x86: Remove swap_task_ctx() kan.liang
2025-03-12 18:25 ` [PATCH V8 6/6] perf: Clean up pmu specific data kan.liang
2025-03-12 19:05 ` [PATCH V8 1/6] perf: Save PMU specific data in task_struct Peter Zijlstra
2025-03-12 19:41 ` Liang, Kan [this message]
2025-03-12 19:43 ` 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=702802d2-7318-4575-81ac-4fad6f8ff42f@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.