From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A814A1F1503 for ; Tue, 21 Jan 2025 12:52:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737463959; cv=none; b=nwLGa93lb2rL6KkkJ4lA6kZX4b3CKPbIQUjfMsS5tZ1yHEGC3mBfHdtSM6PTnXP6+S5cBxuS8YU25krhCZzuUDwspKN1JkcPr+Cqfc/0P8GgtgvIBTcLCF0FbbcK+BaaMR0828mN6Ru+nuZvubGilVatx/KG/sBlIL33vw+9kf8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737463959; c=relaxed/simple; bh=o70jm66G9WY6G/whmJ3r69ivRE7m0ODOrt4/g0I4Azw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VgkjCL+iLRPu6UP3BwBGvRCZdzb7x9i16T0Wlumt5dhMt5nbnDe/gQrBlLe9pOQlGh3w/gdQ4fbDRvFVqH23qGd9CaPELvgBesABTrGyd/d9q6MFZx2zfchf4I8guQ1azlhgkm+8RqusZOR7UgaixcTr0QuQ2bmUmFTlAVlOi0s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=UrhyKHRm; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="UrhyKHRm" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Ek58KfS1jd4DLvMM14E7Mm8y7TPQ6HdnODaOzhsy50s=; b=UrhyKHRm6JY7pPlczTvJMm0vYt 8mPk4NfA7smaYuzFKwL9Y0Y9ZLfEdZTOVjkP8q2KYw0m/w0yT1E6KmKFfy5bcUZLirCHMYpZYmbIr fmCrYMnHuVDJVroug/48cJyKX9c9vZLFJAR7wg8y99EId/PKi4N2R7L3Ngmx6ipXaWAC7lX+0tjip 8eP0+F7VI6h1aSlN8ZQbVSZesBUtocPlIst7EZrlBFbmecLg7LxjdxfR3UJz4UQaXD+zFVWOTFbp8 vOypshtxhADjYehJdkhoePo5V91kCkt7mNS8TQT6jucr7kTEmxyo7Qn4zPD7QLwG+qymYPwyiTeLQ e9ByZ76Q==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1taDk7-0000000DHBA-1320; Tue, 21 Jan 2025 12:52:31 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 36D3E300619; Tue, 21 Jan 2025 13:52:30 +0100 (CET) Date: Tue, 21 Jan 2025 13:52:30 +0100 From: Peter Zijlstra To: "Liang, Kan" Cc: Vince Weaver , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , linux-kernel@vger.kernel.org, Andi Kleen , mathieu.desnoyers@efficios.com Subject: Re: perf: is it possible to userspace rdpmc but only on a certain core type Message-ID: <20250121125230.GD7145@noisy.programming.kicks-ass.net> References: <31ad367a-721f-46e7-8e5f-e96b250a8a32@linux.intel.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: <31ad367a-721f-46e7-8e5f-e96b250a8a32@linux.intel.com> On Mon, Jan 20, 2025 at 11:44:37AM -0500, Liang, Kan wrote: > > > On 2025-01-17 5:04 p.m., Vince Weaver wrote: > > Hello > > > > so we've been working on PAPI support for Intel Top-Down events, which > > let's say does "exciting" things involving the rdpmc instruction. > > > > One issue we are having is that on a hybrid machine (Raptor Lake in this > > case with performance/efficiency cores) there is no top-down support > > for the E-cores, and it will gpf/segfault if you try to rdpmc the top-down > > events. > > > > Obviously PAPI would like to avoid this, and somehow only run the rdpmc > > from userspace if scheduled on a P-core. > > > > Is there any way to atomically do this? Somehow detect what core we are > > on and atomically execute a userspace instruction before a core-reschedule > > can happen? > > > > Or barring that, any other way to handle this in a way that won't crash > > without having to have the users have to bind to a core any time they want > > to run PAPI? > > Can the PAPI rely on the event_idx(), similar to what Andi's pmu-tools > do? For a stopped event, the index is always 0. That's not race-free, the task can get migrated to an E core the moment after you done the load and before the rdpmc instruction. I suppose you can wrap the whole thing in RSEQ though, it's a bit of a pain, but RSEQ can be configured to abort on migration. The very latest libc (2.35+) should have rseq registered by default, older will have to do so itself -- there is example code in tools/testing/selftests/rseq but also https://git.kernel.org/pub/scm/libs/librseq/librseq.git