Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5144425pxb; Mon, 28 Mar 2022 08:32:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2X6GOZegmq9pjIV/JceE2way4cJoy0s6A3QXpI7+Pl1kNpmBDgKr+HROZaRVsCWJNJg71 X-Received: by 2002:aca:a957:0:b0:2ec:9f63:c3d4 with SMTP id s84-20020acaa957000000b002ec9f63c3d4mr16013283oie.230.1648481566960; Mon, 28 Mar 2022 08:32:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648481566; cv=none; d=google.com; s=arc-20160816; b=aWjo0zcq7WPdwhr7XA3sRAWmLGO0ijKVvPK/7rydDklu/6CMaH4q9XDyxL0YUw4eYd 2jfezgxPObsz0l+cCJgLVDEVvnesruyN3pN1XQfJveR+aP+ZZJAL6XAngP7pExrC/fRH FmaZt2Xh1ipkwpW2BowFFvAJsKSbJ84CCi9/TayxJ0xX60I7V52kvVIPJ68ybsPuOwjF C+5CtHtjJ7ZYnQinDjaH2PPWxiMqFgTk4uMPRKcX6MV7M5rM0BS8ANGTETMbxtiQS3fu gskC3W4uxYf5KIG9gQSCrI/J70PhwcpPZf2RB/oa43Z8pApqjVpfqM/K2XfTNDmaWxh0 wMSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=uSPQzhJnBZpuInXUZRxeTEHXo//rS4RqH+94/ELlhDM=; b=kc7GnS5wUIWjR9cMXuOkWkZftX2R7yqD0H5ESjLuohnc/ZPadIQqP3AkLN0d+hvmRQ sGwA74R9ZlTtUGXGIIrdEpA/CQnphpvZCiZzx4L6vqGuidJnDw2iluRzAywZmYxySfIn p4+S+sz9e0D4QN9ZI+4ac34ocRmJ4wrGjpfwOwVlGQda+uqfNfq5e1daeP6mKcZZpiNy E8R7K0a8x1AhiPS3HZG7O41aUB7fvbnyZp7ISursJeXgkNv/z3qXIv04cMNm9mKtzm8N sKnzUNKbbdcm3t3Nc9iZoqys+e0U10bddg50gbYq9m6ku/DK43ZM/9Rl0mNajdRvaK/d CwiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=Y319biAt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y4-20020a056830208400b005cc0ea0de5fsi10331516otq.70.2022.03.28.08.32.33; Mon, 28 Mar 2022 08:32:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=Y319biAt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237675AbiC1Lvk (ORCPT + 99 others); Mon, 28 Mar 2022 07:51:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243298AbiC1Lom (ORCPT ); Mon, 28 Mar 2022 07:44:42 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05AA0574AA; Mon, 28 Mar 2022 04:40:06 -0700 (PDT) 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=uSPQzhJnBZpuInXUZRxeTEHXo//rS4RqH+94/ELlhDM=; b=Y319biAt5K6nejbSVQElCizcwH KshO/fhWzu1hp+KwOwUryrxbQeDmHHG3cgOxCgoW7piq2YJneFquQHl2Ypc/fz8B2txGisxU35L2R N+iwuANB4NrRgWyUv6i38FoskJay75oaezYExrIXi0UX84c0fbRbQuG77f++ywMi423bOYWytesMe NF8/Yem5KYG3fpVA9WSly7w6tnLfdCmR+0P9a/P0TmqVb3D/pukv4HvUBP4c5QCf/50ts4JAY5Z/U +BunOWmHS1ASn87GsmDEGL2Y5TnieEE6dGFQbHJi9xxwfX/Sf9Ek/OaluB4mUZhT+B5MgM6Aszsgr g4H6fshw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nYnit-005Qev-7a; Mon, 28 Mar 2022 11:39:47 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 509969861E7; Mon, 28 Mar 2022 13:39:46 +0200 (CEST) Date: Mon, 28 Mar 2022 13:39:46 +0200 From: Peter Zijlstra To: Namhyung Kim Cc: Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , LKML , Thomas Gleixner , Steven Rostedt , Byungchul Park , "Paul E. McKenney" , Mathieu Desnoyers , Arnd Bergmann , Radoslaw Burny , linux-arch@vger.kernel.org, bpf@vger.kernel.org, Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH 2/2] locking: Apply contention tracepoints in the slow path Message-ID: <20220328113946.GA8939@worktop.programming.kicks-ass.net> References: <20220322185709.141236-1-namhyung@kernel.org> <20220322185709.141236-3-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220322185709.141236-3-namhyung@kernel.org> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 22, 2022 at 11:57:09AM -0700, Namhyung Kim wrote: > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index ee2fd7614a93..c88deda77cf2 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -644,6 +644,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas > } > > set_current_state(state); > + trace_contention_begin(lock, 0); > for (;;) { > bool first; > > @@ -710,6 +711,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas > skip_wait: > /* got the lock - cleanup and rejoice! */ > lock_acquired(&lock->dep_map, ip); > + trace_contention_end(lock, 0); > > if (ww_ctx) > ww_mutex_lock_acquired(ww, ww_ctx); (note: it's possible to get to this trace_contention_end() without ever having passed a _begin -- fixed in the below) > @@ -721,6 +723,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas > err: > __set_current_state(TASK_RUNNING); > __mutex_remove_waiter(lock, &waiter); > + trace_contention_end(lock, ret); > err_early_kill: > raw_spin_unlock(&lock->wait_lock); > debug_mutex_free_waiter(&waiter); So there was one thing here, that might or might not be important, but is somewhat inconsistent with the whole thing. That is, do you want to include optimistic spinning in the contention time or not? Because currently you do it sometimes. Also, if you were to add LCB_F_MUTEX then you could have something like: --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -602,12 +602,14 @@ __mutex_lock_common(struct mutex *lock, preempt_disable(); mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip); + trace_contention_begin(lock, LCB_F_MUTEX | LCB_F_SPIN); if (__mutex_trylock(lock) || mutex_optimistic_spin(lock, ww_ctx, NULL)) { /* got the lock, yay! */ lock_acquired(&lock->dep_map, ip); if (ww_ctx) ww_mutex_set_context_fastpath(ww, ww_ctx); + trace_contention_end(lock, 0); preempt_enable(); return 0; } @@ -644,7 +646,7 @@ __mutex_lock_common(struct mutex *lock, } set_current_state(state); - trace_contention_begin(lock, 0); + trace_contention_begin(lock, LCB_F_MUTEX); for (;;) { bool first; @@ -684,10 +686,16 @@ __mutex_lock_common(struct mutex *lock, * state back to RUNNING and fall through the next schedule(), * or we must see its unlock and acquire. */ - if (__mutex_trylock_or_handoff(lock, first) || - (first && mutex_optimistic_spin(lock, ww_ctx, &waiter))) + if (__mutex_trylock_or_handoff(lock, first)) break; + if (first) { + trace_contention_begin(lock, LCB_F_MUTEX | LCB_F_SPIN); + if (mutex_optimistic_spin(lock, ww_ctx, &waiter)) + break; + trace_contention_begin(lock, LCB_F_MUTEX); + } + raw_spin_lock(&lock->wait_lock); } raw_spin_lock(&lock->wait_lock); @@ -723,8 +731,8 @@ __mutex_lock_common(struct mutex *lock, err: __set_current_state(TASK_RUNNING); __mutex_remove_waiter(lock, &waiter); - trace_contention_end(lock, ret); err_early_kill: + trace_contention_end(lock, ret); raw_spin_unlock(&lock->wait_lock); debug_mutex_free_waiter(&waiter); mutex_release(&lock->dep_map, ip);