[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191202124055.GC2827@hirez.programming.kicks-ass.net>
Date: Mon, 2 Dec 2019 13:40:55 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: mingo@...hat.com, acme@...nel.org, tglx@...utronix.de,
bp@...en8.de, linux-kernel@...r.kernel.org, eranian@...gle.com,
alexey.budankov@...ux.intel.com, vitaly.slobodskoy@...el.com,
ak@...ux.intel.com
Subject: Re: [RFC PATCH 3/8] perf: Init/fini PMU specific data
On Thu, Nov 28, 2019 at 07:14:26AM -0800, kan.liang@...ux.intel.com wrote:
> +static int
> +init_system_wide_ctx_data(size_t ctx_size)
> +{
> + struct task_struct *g, *p;
> + int failed_alloc = 0;
> + unsigned long flags;
> +
> + /*
> + * Allocate perf_ctx_data for all existing threads by the first event.
> + *
> + * The perf_ctx_data for new thread will be allocated in
> + * perf_event_fork(). The perf_event_fork() is called after the thread
> + * is added into the tasklist. It guarantees that any new threads will
> + * not be missed.
> + */
> + raw_spin_lock_irqsave(&task_data_events_lock, flags);
> + if (atomic_inc_return(&nr_task_data_events) > 1)
> + goto unlock;
> +
> + read_lock(&tasklist_lock);
> +
> + for_each_process_thread(g, p) {
> + /*
> + * The PMU specific data may already be allocated by
> + * per-process event. Need to update refcounter.
> + * init_task_ctx_data_rcu() is called here.
> + * Do a quick allocation in first round with GFP_ATOMIC.
> + */
> + if (init_task_ctx_data_rcu(p, ctx_size, GFP_ATOMIC))
> + failed_alloc++;
> + }
This is atricous crap. Also it is completely broken for -RT.
Powered by blists - more mailing lists