[PATCH V2 08/11] coresight: core: Add support for dedicated percpu sinks
Anshuman Khandual
anshuman.khandual at arm.com
Thu Jan 14 21:36:31 EST 2021
On 1/13/21 3:13 PM, Suzuki K Poulose wrote:
> On 1/13/21 4:18 AM, Anshuman Khandual wrote:
>> Add support for dedicated sinks that are bound to individual CPUs. (e.g,
>> TRBE). To allow quicker access to the sink for a given CPU bound source,
>> keep a percpu array of the sink devices. Also, add support for building
>> a path to the CPU local sink from the ETM.
>>
>> This adds a new percpu sink type CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM.
>> This new sink type is exclusively available and can only work with percpu
>> source type device CORESIGHT_DEV_SUBTYPE_SOURCE_PERCPU_PROC.
>>
>> This defines a percpu structure that accommodates a single coresight_device
>> which can be used to store an initialized instance from a sink driver. As
>> these sinks are exclusively linked and dependent on corresponding percpu
>> sources devices, they should also be the default sink device during a perf
>> session.
>>
>> Outwards device connections are scanned while establishing paths between a
>> source and a sink device. But such connections are not present for certain
>> percpu source and sink devices which are exclusively linked and dependent.
>> Build the path directly and skip connection scanning for such devices.
>>
>> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
>> Cc: Mike Leach <mike.leach at linaro.org>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++++++
>> include/linux/coresight.h | 12 ++++++++++++
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
>> index 0062c89..b300606 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -23,6 +23,7 @@
>> #include "coresight-priv.h"
>> static DEFINE_MUTEX(coresight_mutex);
>> +DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
>> /**
>> * struct coresight_node - elements of a path, from source to sink
>> @@ -784,6 +785,13 @@ static int _coresight_build_path(struct coresight_device *csdev,
>> if (csdev == sink)
>> goto out;
>> + if (coresight_is_percpu_source(csdev) && coresight_is_percpu_sink(sink) &&
>> + sink == per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev))) {
>> + _coresight_build_path(sink, sink, path);
>> + found = true;
>> + goto out;
>> + }
>> +
>> /* Not a sink - recursively explore each port found on this element */
>> for (i = 0; i < csdev->pdata->nr_outport; i++) {
>> struct coresight_device *child_dev;
>> @@ -998,6 +1006,12 @@ coresight_find_default_sink(struct coresight_device *csdev)
>> {
>> int depth = 0;
>> + if (coresight_is_percpu_source(csdev)) {
>
> On a system without per_cpu sink, this would reset the default sink for the source device
> every single time and fallback to searching every single time.
Right.
> So I think it would be better if did check if the def_sink was not set.
> We could fold this into the case below may be. i.e,
>
>
> if (!csdev->def_sink) {
> if (coresight_is_percpu_source(csdev))
> csdev->def_sink = per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev));
> if (!csdev->def_sink) csdev->def_sink = coresight_find_sink(csdev, &depth);
> }
>
> Otherwise looks good to me.
struct coresight_device *
coresight_find_default_sink(struct coresight_device *csdev)
{
int depth = 0;
/* look for a default sink if we have not found for this device */
if (!csdev->def_sink) {
if (coresight_is_percpu_source(csdev))
csdev->def_sink = per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev));
if (!csdev->def_sink)
csdev->def_sink = coresight_find_sink(csdev, &depth);
}
return csdev->def_sink;
}
Would this be better instead ? coresight_find_sink() is invoked both when the
source is not percpu (traditional coresight sources) and also as a fallback in
case a percpu sink is not found for the percpu source device.
More information about the linux-arm-kernel
mailing list