From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) (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 212DA402B83 for ; Thu, 26 Mar 2026 16:46:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774543584; cv=none; b=Tr1vTpDNJxz0TB+DsV8QzypZez0giO2/0VJ89NoZhOTkEwkWncsUkcuMuNQ2C5r2LQDglozsZjf7YUurV8XGcl4+xUCAKDkc+Qe3iVHuVf+VmCVUBRkv6+MSOKozBnirfAkdXAqL8MwXvSPZqaD4uyP9jLURwY9UoK6ZqmyVp7w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774543584; c=relaxed/simple; bh=IrNMG8JzJf0gLtDRAMekvNsaWFh/Zj1yl1xgjQeFBX8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=l5OZZNYtOi+/cUwgQqWM16l7QHXZiht2UyNs17+kCBfbtupgsagydT8cRoDyN59e2CxtWc/qeLqvfsvYtRAYc/fsTrKlkhtPoq3k+DtASL+e45Hs6phZMnA+GyrNOlcvCckxYioR8b3ojhniTATCWVBVBRq3iVqrPPb4mnBNq8s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 96E35140E1C; Thu, 26 Mar 2026 16:46:13 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf07.hostedemail.com (Postfix) with ESMTPA id AA7C220032; Thu, 26 Mar 2026 16:46:07 +0000 (UTC) Date: Thu, 26 Mar 2026 12:46:54 -0400 From: Steven Rostedt To: Matthew Wilcox Cc: Dmitry Ilvokhin , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Thomas Bogendoerfer , Juergen Gross , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Arnd Bergmann , Dennis Zhou , Tejun Heo , Christoph Lameter , Masami Hiramatsu , Mathieu Desnoyers , linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, virtualization@lists.linux.dev, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v4 0/5] locking: contended_release tracepoint instrumentation Message-ID: <20260326124654.66b4dbc1@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: oxpnmau35kmgbeef69arytyyqjdq4tcm X-Rspamd-Server: rspamout02 X-Rspamd-Queue-Id: AA7C220032 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX18T30hkquOyghpO0b3wg7U69NQLAoKWLEI= X-HE-Tag: 1774543567-165604 X-HE-Meta: U2FsdGVkX1+aucRsg/fJwSO9PcSLmk9Uk3XJJ6a8zNjBvZXhrYnWw8QuFZDYOQAZcKByDBMi6oGlRWtTF/Acf81GjhgOA6h7nGVnnpPy9E5e0/5WaXs311Ddp5diPLuMOv2IW38+0Dk/6tOn+Zkvvq989+N+UF2XvBrebx1sWJWtvBgdDrf9ptRKO/b1FQfSq2VqlITHIQYMVZy7JK1h3nZDehd2eU/kzpM76hR0FzJKGqVYc7rtfpxOV3e5SKzZPSzkoOwAOuxo4uaGOxH6Qi1DWYPmS90pi+Lwbv2tjNOCuDuR2Jn16cNcy8fcYO0C5X4AfXaiHii7M18gBqE54UkvWLH/jjdU1XUWoqlX11A9Tv93kHbWpf7w0uUHT93G On Thu, 26 Mar 2026 15:55:21 +0000 Matthew Wilcox wrote: > > - The holder's stack at release time, which may differ from what perf lock > > contention --lock-owner captures if the holder does significant work between > > the waiter's arrival and the unlock. > > As someone who's not an expert in this area (so please use short words > to explain it to me), why do we want to know how long this holder took > to release the lock from when it became contended? > > I understand why we want to know how long any given waiter had to wait > to gain the lock (but we already have tracepoints which show that). > > I also don't understand why we want to know the holder's stack at > release time. The stack at contention-begin time will include > the point at which the lock was acquired which should be correlated > with where the lock was released. > > Perhaps examples might help me understand why we want this? Dmitry could give his own rationale for this, but I have my only use case. This would be useful to find out how long the critical section is. If a lock is highly contended by many tasks, you could get a high contention time simply because other tasks are causing the delay for the waiter. Seeing the release time and location would let you also know how long the critical section was held, and if the length of the critical section is causing the contention. Having a stack trace of the release would differentiate the path that released the lock, as there can be many places that release them. Although, I have to admit, I'm not sure there are many different places locks are released. Especially now that we have guard(), which will make all the releases in a function at the same location. -- Steve