Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1485128 > unrolled thread

Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver Neil Leeder <nleeder@codeaurora.org> - 2016-09-16 17:40 +0200
    Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver Mark Rutland <mark.rutland@arm.com> - 2016-09-16 18:50 +0200
      Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver Neil Leeder <nleeder@codeaurora.org> - 2016-09-16 22:00 +0200

#1485128 — Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

Hi Mark,
Thank you for the thorough review. I will post an updated patchset which addresses
all of your comments. There is just one outstanding comment which I have a question about:

On 9/1/2016 12:30 PM, Mark Rutland wrote:
> On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:

>> +static int l2_cache__event_init(struct perf_event *event)
>> +{
>> +	struct hw_perf_event *hwc = &event->hw;
>> +	struct hml2_pmu *slice;
>> +	struct perf_event *sibling;
>> +	struct l2cache_pmu *l2cache_pmu = to_l2cache_pmu(event->pmu);
>> +
>> +	if (event->attr.type != l2cache_pmu->pmu.type)
>> +		return -ENOENT;
>> +
>> +	if (hwc->sample_period) {
>> +		dev_warn(&l2cache_pmu->pdev->dev, "Sampling not supported\n");
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	if (event->cpu < 0) {
>> +		dev_warn(&l2cache_pmu->pdev->dev, "Per-task mode not supported\n");
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	/* We cannot filter accurately so we just don't allow it. */
>> +	if (event->attr.exclude_user || event->attr.exclude_kernel ||
>> +	    event->attr.exclude_hv || event->attr.exclude_idle) {
>> +		dev_warn(&l2cache_pmu->pdev->dev, "Can't exclude execution levels\n");
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	if (((L2_EVT_GROUP(event->attr.config) > L2_EVT_GROUP_MAX) ||
>> +	    (L2_EVT_PREFIX(event->attr.config) != 0) ||
>> +	    (L2_EVT_REG(event->attr.config) != 0)) &&
>> +	    (event->attr.config != L2CYCLE_CTR_RAW_CODE)) {
>> +		dev_warn(&l2cache_pmu->pdev->dev, "Invalid config %llx\n",
>> +			 event->attr.config);
>> +		return -EINVAL;
>> +	}
>> +
>> +	/* Don't allow groups with mixed PMUs, except for s/w events */
>> +	if (event->group_leader->pmu != event->pmu &&
>> +	    !is_software_event(event->group_leader)) {
>> +		dev_warn(&l2cache_pmu->pdev->dev,
>> +			 "Can't create mixed PMU group\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	list_for_each_entry(sibling, &event->group_leader->sibling_list,
>> +			    group_entry)
>> +		if (sibling->pmu != event->pmu &&
>> +		    !is_software_event(sibling)) {
>> +			dev_warn(&l2cache_pmu->pdev->dev,
>> +				 "Can't create mixed PMU group\n");
>> +			return -EINVAL;
>> +		}
>> +
>> +	hwc->idx = -1;
>> +	hwc->config_base = event->attr.config;
>> +
>> +	/*
>> +	 * Ensure all events are on the same cpu so all events are in the
>> +	 * same cpu context, to avoid races on pmu_enable etc.
>> +	 */
>> +	slice = get_hml2_pmu(event->cpu);
>> +	event->cpu = slice->on_cpu;
> 
> This could put an event on a different CPU to its group siblings, which
> is broken.

This is the same logic as in arm-ccn.c:arm_ccn_pmu_event_init(), where there
is a single CPU designated as the CPU to be used for all events. All
events for this slice are forced to slice->on_cpu which is the CPU set in the
cpumask for this slice.

I'm not sure how this can put an event on a different CPU to its group siblings?

Thanks,
Neil
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[toc] | [next] | [standalone]

#1485172

On Fri, Sep 16, 2016 at 11:33:39AM -0400, Neil Leeder wrote:
> Hi Mark,
> Thank you for the thorough review. I will post an updated patchset
> which addresses all of your comments. There is just one outstanding
> comment which I have a question about:

[...]

> On 9/1/2016 12:30 PM, Mark Rutland wrote:
> > On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:
> >> +	/* Don't allow groups with mixed PMUs, except for s/w events */
> >> +	if (event->group_leader->pmu != event->pmu &&
> >> +	    !is_software_event(event->group_leader)) {
> >> +		dev_warn(&l2cache_pmu->pdev->dev,
> >> +			 "Can't create mixed PMU group\n");
> >> +		return -EINVAL;
> >> +	}
> >> +
> >> +	list_for_each_entry(sibling, &event->group_leader->sibling_list,
> >> +			    group_entry)
> >> +		if (sibling->pmu != event->pmu &&
> >> +		    !is_software_event(sibling)) {
> >> +			dev_warn(&l2cache_pmu->pdev->dev,
> >> +				 "Can't create mixed PMU group\n");
> >> +			return -EINVAL;
> >> +		}
> >> +
> >> +	hwc->idx = -1;
> >> +	hwc->config_base = event->attr.config;
> >> +
> >> +	/*
> >> +	 * Ensure all events are on the same cpu so all events are in the
> >> +	 * same cpu context, to avoid races on pmu_enable etc.
> >> +	 */
> >> +	slice = get_hml2_pmu(event->cpu);
> >> +	event->cpu = slice->on_cpu;
> > 
> > This could put an event on a different CPU to its group siblings, which
> > is broken.
> 
> This is the same logic as in arm-ccn.c:arm_ccn_pmu_event_init(), where there
> is a single CPU designated as the CPU to be used for all events.
>
> All events for this slice are forced to slice->on_cpu which is the CPU
> set in the cpumask for this slice.

The CCN is a little different. For the CCN, a single CPU is designated
to handle *all* events.

For this driver, a CPU is designated per-slice, judging by the existence
of hml2_pmu::on_cpu (unless that's superfluous). We've only verified
that the events are all for this PMU, not the same slice, and thus each
event->cpu may differ.

> I'm not sure how this can put an event on a different CPU to its group
> siblings?

In practice today, we'll try to schedule the event on it's group
leader's CPU, but accounting and subsequent manipulation could go wrong.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1485291

On 9/16/2016 12:40 PM, Mark Rutland wrote:
> On Fri, Sep 16, 2016 at 11:33:39AM -0400, Neil Leeder wrote:
[...]
>> On 9/1/2016 12:30 PM, Mark Rutland wrote:
>>> On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:
>>>> +	/* Don't allow groups with mixed PMUs, except for s/w events */
>>>> +	if (event->group_leader->pmu != event->pmu &&
>>>> +	    !is_software_event(event->group_leader)) {
>>>> +		dev_warn(&l2cache_pmu->pdev->dev,
>>>> +			 "Can't create mixed PMU group\n");
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	list_for_each_entry(sibling, &event->group_leader->sibling_list,
>>>> +			    group_entry)
>>>> +		if (sibling->pmu != event->pmu &&
>>>> +		    !is_software_event(sibling)) {
>>>> +			dev_warn(&l2cache_pmu->pdev->dev,
>>>> +				 "Can't create mixed PMU group\n");
>>>> +			return -EINVAL;
>>>> +		}
>>>> +
>>>> +	hwc->idx = -1;
>>>> +	hwc->config_base = event->attr.config;
>>>> +
>>>> +	/*
>>>> +	 * Ensure all events are on the same cpu so all events are in the
>>>> +	 * same cpu context, to avoid races on pmu_enable etc.
>>>> +	 */
>>>> +	slice = get_hml2_pmu(event->cpu);
>>>> +	event->cpu = slice->on_cpu;
>>>
>>> This could put an event on a different CPU to its group siblings, which
>>> is broken.
>>
>> This is the same logic as in arm-ccn.c:arm_ccn_pmu_event_init(), where there
>> is a single CPU designated as the CPU to be used for all events.
>>
>> All events for this slice are forced to slice->on_cpu which is the CPU
>> set in the cpumask for this slice.
> 
> The CCN is a little different. For the CCN, a single CPU is designated
> to handle *all* events.
> 
> For this driver, a CPU is designated per-slice, judging by the existence
> of hml2_pmu::on_cpu (unless that's superfluous). We've only verified
> that the events are all for this PMU, not the same slice, and thus each
> event->cpu may differ.
> 

I see. So I can add a check that the group_leader event must be on the
same slice, and thus on the same CPU.

>> I'm not sure how this can put an event on a different CPU to its group
>> siblings?
> 
> In practice today, we'll try to schedule the event on it's group
> leader's CPU, but accounting and subsequent manipulation could go wrong.
> 
> Thanks,
> Mark.
> 

Neil
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web