All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
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 20:05:33 +0100	[thread overview]
Message-ID: <20250312190533.GA10453@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250312182525.4078433-1-kan.liang@linux.intel.com>


I'm sorry, but since I spotted a bug in the second patch, I'm going to
reply and suggest some overall changes.

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?

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);



  parent reply	other threads:[~2025-03-12 19:05 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 ` Peter Zijlstra [this message]
2025-03-12 19:41   ` [PATCH V8 1/6] perf: Save PMU specific data in task_struct Liang, Kan
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=20250312190533.GA10453@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.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.