From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CD77248C8D7 for ; Tue, 25 Aug 2026 17:32:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787679157; cv=none; b=kR2/YnvEPiZQHLjLMDysFmh5W/ZZova0zHFjnVNEqPvR+kL7DnnYX+hhd4mw/k4/oIbZtFWNP2MZL5edIrv7BJQ/SyJK23wTqU0B/hLgs1PqUteDRR7ShoxjIptDF99KThnYQ1K8m/75Zr6aIUXDNbM1TsAo67EL8oi0cDKUf9c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787679157; c=relaxed/simple; bh=q1Lqfg3g5fiRXim4OSaoLhq/YwRQEguS7BM61Mgap40=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H+SsFQHFeQXr59KCR5XRDHx9AXw4WPnjYKI67MlkIrxNiuULmcHxKRe11NQV7QP0QMeSBA/aoENbG2BlKbZG4A/qvHSp01fhR0qnZXOozz7PmRqXyl6H1VoeMYosH4GM4avsy7F/IHMkvsU82N8gy++/SgmXTqDGj/DD0ijpMVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=R+9DQjP+; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="R+9DQjP+" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 343261A9A; Tue, 25 Aug 2026 10:32:19 -0700 (PDT) Received: from localhost (unknown [10.2.196.114]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1E5D3F85F; Tue, 25 Aug 2026 10:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1787679143; bh=q1Lqfg3g5fiRXim4OSaoLhq/YwRQEguS7BM61Mgap40=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R+9DQjP+y9cNuiOismBM8Ue92KCRXT3qeaDf/+3wUgqo8h44U1PzjTArLEz9BGf+o ywA5dEy+4uCI/J9ChI7KVR6TGxY0CSH9nOqcsCiaCCPfsmjUSEhgEmD1AAkUAvpvFg oIbCl7UTxxbMCgE289Fuu2ciWV1dg6y3S2IDaE/I= Date: Tue, 25 Aug 2026 18:32:20 +0100 From: Leo Yan To: James Clark Cc: Suzuki K Poulose , Mike Leach , Suyash Mahar , Yeoreum Yun , Greg Kroah-Hartman , Qi Liu , Junhao He , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jonathan Cameron Subject: Re: [PATCH v3 4/8] coresight: tmc-etr: Prevent per-thread events from sharing a sink Message-ID: <20260825173220.GG8904@e132581.arm.com> References: <20260728-james-cs-multiple-per-threads-v3-0-6aee7579f1dc@linaro.org> <20260728-james-cs-multiple-per-threads-v3-4-6aee7579f1dc@linaro.org> <20260813160504.GC8904@e132581.arm.com> <20260819084515.GF8904@e132581.arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Aug 20, 2026 at 12:09:25PM +0100, James Clark wrote: [...] > > I am just wandering if we can improve the sink driver to only allocate > > a single bounce buffer that is independent of any threads (and any > > associated events). > > > > | T1 | > > CPU0 ------------------------------ > > | T2 | > > CPU1 ------------------------------ > > `> T2 stops and can sync trace > > from the shared bounce buffer > > to AUX_BUF(T2). > > > > AUX_BUF(T1) | | > > AUX_BUF(T2) | | > > > > ETR_BUF | Bounce buf | -> Used by H/W trace > > > > This might also simplify the CPU-wide case. Each CPU would still have > > its own AUX buffer, but the ETR driver would maintain only one bounce > > buffer for the shared sink. A reference count could track how many > > events are using the sink, with the final event responsible for > > Isn't this how it's already working? get_perf_etr_buf_cpu_wide() allocates a > single shared buffer with a refcount. I didn't change this, I only changed > the rules about what is considered shared or not so that it matches the > semantics of the perf events that back the tracing session. I think this is slightly different from my point. The CPU-wide path already uses a shared buffer with a reference count to support multiple events, while the per-thread path does not. For the longe term, I would prefer to unify the sink buffer management. Ideally, ETR/ETF/ETB should manage the sink buffer in the same way regardless of whether the users come from CPU-wide or per-thread modes. This would keep perf event semantics out of the low-level sink drivers as much as possible. However, this would be a larger change and we could defer in the future. Now I treat the multiple events in per-thread mode as an implementation limitation. For the immediate fix, we just reject this case instead. > > We use a central place etm_event_build_path() to record and compare > > event's owner and target process, then we don't need to spread the > > check into sink drivers. We only care about if owner and target must > > be consistent. I experimented with moving the check to a common place during buffer allocation: https://termbin.com/dib3r It needs locking to keep the check in atomicity, but seems doable. We don't need to spread event checks across the different sink drivers. > But we don't know where the target will run when the event is created. > That's why the check is delayed until etm_event_start() and the process has > been scheduled. Where it runs needs to be taken into account to calculate if > this sink can be shared. Adding the check in etm_event_start() makes the result depend on task scheduling. I understand some cases you mentioned may benefit from this, but it also makes the behaviour less deterministic. I would prefer to reject unsupported cases explicitly when opening the events. Thanks, Leo