mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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