From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>, Andi Kleen <ak@linux.intel.com>
Cc: mingo@redhat.com, acme@kernel.org, tglx@linutronix.de,
bp@alien8.de, linux-kernel@vger.kernel.org, eranian@google.com,
alexey.budankov@linux.intel.com, vitaly.slobodskoy@intel.com
Subject: Re: [RFC PATCH V2 2/7] perf: Init/fini PMU specific data
Date: Mon, 6 Jan 2020 11:18:24 -0500 [thread overview]
Message-ID: <e12e347e-505e-2703-537f-c4394bebce89@linux.intel.com> (raw)
In-Reply-To: <20200106143138.GN2844@hirez.programming.kicks-ass.net>
On 1/6/2020 9:31 AM, Peter Zijlstra wrote:
> On Mon, Jan 06, 2020 at 06:23:43AM -0800, Andi Kleen wrote:
>>>> + rcu_read_lock();
>>>> + for_each_process_thread(g, p) {
>>>> + mutex_lock(&p->perf_event_mutex);
>>>> + if (p->perf_ctx_data) {
>>>> + /*
>>>> + * The perf_ctx_data for this thread may has been
>>>> + * allocated by per-task event.
>>>> + * Only update refcount for the case.
>>>> + */
>>>> + refcount_inc(&p->perf_ctx_data->refcount);
>>>> + mutex_unlock(&p->perf_event_mutex);
>>>> + continue;
>>>> + }
>>>> +
>>>> + if (pos < num_thread) {
>>>> + refcount_set(&data[pos]->refcount, 1);
>>>> + rcu_assign_pointer(p->perf_ctx_data, data[pos++]);
>>>> + } else {
>>>> + /*
>>>> + * There may be some new threads created,
>>>> + * when we allocate space.
>>>> + * Track the number in nr_new_tasks.
>>>> + */
>>>> + nr_new_tasks++;
>>>> + }
>>>> + mutex_unlock(&p->perf_event_mutex);
>>>> + }
>>>> + rcu_read_unlock();
>>>> +
>>>> + raw_spin_unlock_irqrestore(&task_data_sys_wide_events_lock, flags);
>>>
>>> Still NAK. That's some mightly broken code there.
>>
>> Yes, Kan you cannot use a mutex (sleeping) inside rcu_read_lock().
>> Can perf_event_mutex be a spin lock?
>
> Or insize that raw_spin_lock.
The task_data_sys_wide_events_lock is a global lock. I think we just
need per-task lock here.
I think I will add a new dedicate per-task raw_spin_lock for
perf_ctx_data here.
> And last time I expressly said to not do
> what whole tasklist iteration under a spinlock.
>
We need an indicator to tell if the assignment for all existing tasks
has been finished. Because we have to wait before processing the cases
as below.
- Allocate the space for new threads. If we don't wait the assignments
finished, we cannot tell if the perf_ctx_data is allocated by previous
per-task event, or this system-wide event. The refcount may double count.
- There may be two or more system-wide events at the same time. When we
are allocating the space for the first event, the second one may start
profiling if we don't wait. The LBR shorten issue still exists.
- We have to serialize assignment and free.
If we cannot use spinlock to serialize the cases here, can we set a
state when the assignment is finished, and use wait_var_event() in the
cases as above?
Thanks,
Kan
next prev parent reply other threads:[~2020-01-06 16:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 19:39 [RFC PATCH V2 1/7] perf: Save PMU specific data in task_struct kan.liang
2020-01-03 19:39 ` [RFC PATCH V2 2/7] perf: Init/fini PMU specific data kan.liang
2020-01-06 10:38 ` Peter Zijlstra
2020-01-06 14:23 ` Andi Kleen
2020-01-06 14:31 ` Peter Zijlstra
2020-01-06 16:18 ` Liang, Kan [this message]
2020-01-03 19:39 ` [RFC PATCH V2 3/7] perf: Supply task information to sched_task() kan.liang
2020-01-03 19:39 ` [RFC PATCH V2 4/7] perf/x86/lbr: Fix shorter LBRs call stacks for system-wide mode kan.liang
2020-01-03 19:39 ` [RFC PATCH V2 5/7] perf/x86: Remove swap_task_ctx() kan.liang
2020-01-03 19:39 ` [RFC PATCH V2 6/7] perf: Clean up pmu specific data kan.liang
2020-01-03 19:39 ` [RFC PATCH V2 7/7] perf: Clean up event context from sched_task() kan.liang
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=e12e347e-505e-2703-537f-c4394bebce89@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vitaly.slobodskoy@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
Powered by JetHome