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;
From:   Jonas Oberhauser <jonas.oberhauser@huawei.com>
To:     "paulmck@kernel.org" <paulmck@kernel.org>,
        "riel@surriel.com" <riel@surriel.com>,
        "davej@codemonkey.org.uk" <davej@codemonkey.org.uk>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kernel-team@meta.com" <kernel-team@meta.com>
Subject: RE: [PATCH diagnostic qspinlock] Diagnostics for excessive lock-drop
 wait loop time
Thread-Topic: [PATCH diagnostic qspinlock] Diagnostics for excessive lock-drop
 wait loop time
Thread-Index: AQHZJh4apQ0ukQ/LOEaXjXF7PGrkyq6a/rvg
Date:   Thu, 12 Jan 2023 20:51:04 +0000
Message-ID: <896a2d84918e4adc8a4d00d72510eb3d@huawei.com>
References: <20230112003627.GA3133092@paulmck-ThinkPad-P17-Gen-1>
In-Reply-To: <20230112003627.GA3133092@paulmck-ThinkPad-P17-Gen-1>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Precedence: bulk

Hi Paul,

-----Original Message-----
From: Paul E. McKenney [mailto:paulmck@kernel.org] 
> We see systems stuck in the queued_spin_lock_slowpath() loop that waits for the lock to become unlocked in the case where the current CPU has set pending state.

Interesting!
Do you know if the hangs started with a recent patch? What codepaths are active (virtualization/arch/...)? Does it happen extremely rarely? Do you have any additional information?

I saw a similar situation a few years ago in a proprietary kernel, but it only happened once ever and I gave up on looking for the reason after a few days (including some time combing through the compiler generated assembler).

Have fun,
jonas