From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2DB4C2D0A3 for ; Mon, 26 Oct 2020 04:36:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2EB812084C for ; Mon, 26 Oct 2020 04:36:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="s4/xmRdW"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cm/DtMbZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EB812084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XUZeuEQXQho/qwKO0fJzreSM6ZSGlLDIZ/u5OpvF3r4=; b=s4/xmRdWEjmw7+zA+dKhXwcOj VHu+2HLXNDfqjzK9Z7umnZiU8zhrvcOGPXuflkVDePcxhjlsTb0tBROsCbq8Y9SJYfGOlO3rxRT65 oazbPKm0nVLN9fdPgwdx32MFrmZDO6uj94WBBVhyoQ7mJDXc7DJi1iFkpzLF5IrnksepbhQZCqcai TwBXMr83n6gvF4Btc0nnyh+UwT5ZthHvEfUQ/JhEu0jwMODxZX/IFrG98Wgc7B43eZjugSYxL4u1X XdJ7wijseNiqoBOHXcop0+enHTgaxSIZnJmL+Bm/uyahKl37+KUocrQcCe9627+sBYNxHtWZixmpw 6mqTPc/yA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWuD2-0004rE-2T; Mon, 26 Oct 2020 04:34:16 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWuCy-0004qu-QU for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 04:34:14 +0000 Received: by mail-lf1-x141.google.com with SMTP id z2so10090624lfr.1 for ; Sun, 25 Oct 2020 21:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iNjVttWmfva0n4cAX5hcfFaqdpEUuJPofpN36b5gwMs=; b=cm/DtMbZvUFNNDZvL3IGevkSYphKUWUjBxsWqbcaemuSOjmqIYiaaGvROPDeRIqbnJ VwywGbEQDGgcGKZ27P7wqwiWxHBGuZGe9Js/LTg4HmZG9cNQD4eJcBDLcJoSOksYklao hqWUIZMEtIca3LpYrvmCceXleucJrggV8oH555SX2nTXol4xEgOgUSV8eZ8qQcCShIEA kiYoTJWSSzfPXQqu5HtvzDLfdijUe/FZAnE69Otwhu+/0XB7CG+3nYzDKJmthA7rNkhc tSLud8pSruvZaeC4x0BhDIY+smIpoxODHZCA+XOakNL18vA1HQ9BUzkRgfi4E4kLTrF6 Yilw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iNjVttWmfva0n4cAX5hcfFaqdpEUuJPofpN36b5gwMs=; b=cyVMM1U4VXBqCMnjCsMbc30sZ9T2v51twr1DSXVs9UihoXr5wluh7WaUgMVctmtgBl RpRfK2IJ4VD21VPI82p5Xx9M065sFoCIHzDlOuj3Ud8xqwVoxm1sSlh8FjSQgZiMob3l dQzYvm+RwIBX2c+gz34mSmP0JyQlxwrUFVCQ7Ph224Jk1kwHTNjqhEyxbqAGmelXLMSC palzGsL9j77wlSoNhi1PI0M+h0y/J7TgHTVWXy6auE5zqMJruxlEKV2RTnTTdMsz9/sG 40/PqP+m2WMY746vuniCW+HkefZCqo8FPO6VomOyk9uS/cSLUlSkMm2Os1KWiwhDaWFe omeg== X-Gm-Message-State: AOAM532JQa+1w47iyQSSOYfPv/gKIyDMIO7YL3+ZWI6VUzj3Ikz8RSCq 8/GNK4QeXIhJUL/TeTmlvM9k9qVMf1GsfqVf+zg= X-Google-Smtp-Source: ABdhPJzBzba0WnnNMuwESSUaBz/KJriPxvbTclZRM09TfC3nRdGBeggstvT5u4FyjKYBNCaWtL8GWKwDfHtq1O1a6BI= X-Received: by 2002:a05:6512:209:: with SMTP id a9mr4166141lfo.309.1603686849371; Sun, 25 Oct 2020 21:34:09 -0700 (PDT) MIME-Version: 1.0 References: <20200904024106.21478-1-lcherian@marvell.com> <2bd65f2d-5660-10b3-f51f-448221d78d3d@arm.com> In-Reply-To: <2bd65f2d-5660-10b3-f51f-448221d78d3d@arm.com> From: Linu Cherian Date: Mon, 26 Oct 2020 10:03:57 +0530 Message-ID: Subject: Re: [PATCH v4 0/2] Make sysFS functional on topologies with per core sink To: Suzuki K Poulose X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_003412_978003_BEB7F7DB X-CRM114-Status: GOOD ( 46.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel , Coresight ML , Mathieu Poirier , Linu Cherian , Mike Leach Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Suzuki, On Mon, Oct 5, 2020 at 4:52 PM Suzuki K Poulose wrote: > > Hi Linu, > > On 09/04/2020 03:41 AM, Linu Cherian wrote: > > This patch series tries to fix the sysfs breakage on topologies > > with per core sink. > > > > Changes since v3: > > - References to coresight_get_enabled_sink in perf interface > > has been removed and marked deprecated as a new patch. > > - To avoid changes to coresight_find_sink for ease of maintenance, > > search function specific to sysfs usage has been added. > > - Sysfs being the only user for coresight_get_enabled sink, > > reset option is removed as well. > > Have you tried running perf with --per-thread option ? I believe > this will be impacted as well, as we choose a single sink at the > moment and this may not be reachable from the other CPUs, where > the event may be scheduled. Eventually loosing trace for the > duration where the task is scheduled on a different CPU. > > Please could you try this patch and see if helps ? I have lightly > tested this on a fast model. We are seeing some issues while testing with this patch. The issue is that, always buffer allocation for the sink happens to be on the first core in cpu mask and this doesn't match with the core on which event is started. Please see below for additional comments. > > ---8>--- > > coresight: etm-perf: Allow an event to use multiple sinks > > When there are multiple sinks on the system, in the absence > of a specified sink, it is quite possible that a default sink > for an ETM could be different from that of another ETM (e.g, on > systems with per-CPU sinks). However we do not support having > multiple sinks for an event yet. This patch allows the event to > use the default sinks on the ETMs where they are scheduled as > long as the sinks are of the same type. > > e.g, if we have 1x1 topology with per-CPU ETRs, the event can > use the per-CPU ETR for the session. However, if the sinks > are of different type, e.g TMC-ETR on one and a custom sink > on another, the event will only trace on the first detected > sink (just like we have today). > > Cc: Linu Cherian > Cc: Mathieu Poirier > Cc: Mike Leach > Signed-off-by: Suzuki K Poulose > --- > .../hwtracing/coresight/coresight-etm-perf.c | 69 +++++++++++++------ > 1 file changed, 49 insertions(+), 20 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c > b/drivers/hwtracing/coresight/coresight-etm-perf.c > index c2c9b127d074..19fe38010474 100644 > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c > @@ -204,14 +204,28 @@ static void etm_free_aux(void *data) > schedule_work(&event_data->work); > } > > +/* > + * When an event could be scheduled on more than one CPUs, we have to make > + * sure that the sinks are of the same type, so that the sink_buffer could > + * be reused. > + */ > +static bool sinks_match(struct coresight_device *a, struct coresight_device *b) > +{ > + if (!a || !b) > + return false; > + return (sink_ops(a) == sink_ops(b)) && > + (a->subtype.sink_subtype == b->subtype.sink_subtype); > +} > + > static void *etm_setup_aux(struct perf_event *event, void **pages, > int nr_pages, bool overwrite) > { > u32 id; > int cpu = event->cpu; > cpumask_t *mask; > - struct coresight_device *sink; > + struct coresight_device *sink = NULL; > struct etm_event_data *event_data = NULL; > + bool sink_forced = false; > > event_data = alloc_event_data(cpu); > if (!event_data) > @@ -222,6 +236,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, > if (event->attr.config2) { > id = (u32)event->attr.config2; > sink = coresight_get_sink_by_id(id); > + sink_forced = true; > } > > mask = &event_data->mask; > @@ -235,7 +250,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, > */ > for_each_cpu(cpu, mask) { > struct list_head *path; > - struct coresight_device *csdev; > + struct coresight_device *csdev, *cpu_sink; > > csdev = per_cpu(csdev_src, cpu); > /* > @@ -243,33 +258,42 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, > * the mask and continue with the rest. If ever we try to trace > * on this CPU, we handle it accordingly. > */ > - if (!csdev) { > - cpumask_clear_cpu(cpu, mask); > - continue; > - } > - > + if (!csdev) > + goto clear_cpu; > /* > - * No sink provided - look for a default sink for one of the > - * devices. At present we only support topology where all CPUs > - * use the same sink [N:1], so only need to find one sink. The > - * coresight_build_path later will remove any CPU that does not > - * attach to the sink, or if we have not found a sink. > + * No sink provided - look for a default sink for all the devices. > + * We only support multiple sinks, only if all the default sinks > + * are of the same type, so that the sink buffer can be shared > + * as the event moves around. As earlier, we don't trace on a > + * CPU, if we can't find a suitable sink. > */ > - if (!sink) > - sink = coresight_find_default_sink(csdev); > + if (!sink_forced) { > + cpu_sink = coresight_find_default_sink(csdev); > + if (!cpu_sink) > + goto clear_cpu; > + /* First sink for this event */ > + if (!sink) { > + sink = cpu_sink; > + } else if (!sinks_match(cpu_sink, sink)) { > + goto clear_cpu; > + } > In per-thread option, cpu_sink always happens to be on core 0, since all cores are enabled in the cpu mask. So feels like we need to take into consideration of the core on which the event gets started(the core on which the process gets executed) while doing the buffer allocation. On a related note, I had another question on this. Don't we also need to address cases when multiple threads are forked in a process ? Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel