From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC611C021B3 for ; Thu, 20 Feb 2025 09:25:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26F192802B6; Thu, 20 Feb 2025 04:25:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18275280003; Thu, 20 Feb 2025 04:25:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F16D8280002; Thu, 20 Feb 2025 04:25:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CEE43280001 for ; Thu, 20 Feb 2025 04:25:38 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9288E16012F for ; Thu, 20 Feb 2025 09:25:38 +0000 (UTC) X-FDA: 83139790356.16.C37104A Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id D6B00C000E for ; Thu, 20 Feb 2025 09:25:36 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eHfDlng0; spf=pass (imf22.hostedemail.com: domain of mhiramat@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740043536; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ySwZ6XB/mEkXa9IAGNFoEGO5Wvlpx5z7n2usl1PgsUo=; b=3JJGtjPPquzhYRwAnh2DJF2o4kflRNQmXtmEoHe7kG7rszfZUgq2QGQ+DMrc2wWiMGH4Kl njQEpgLlgwz3fiUOkDJqHjee0dOn/I5fVRrmB4jt/Re2jd7vv3VeQkg5ic8x0kiSGQ9ysZ HU2b/s5Hu/ogiub3KV/8xBQM/aIyKdA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eHfDlng0; spf=pass (imf22.hostedemail.com: domain of mhiramat@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740043536; a=rsa-sha256; cv=none; b=rQqXsqHo4edRKCSwkAzCAJ7d6X7LB/Zkst50tuzDlyYDgu0vpaS6qQJtOvaEzFe9unNf6u OtSbLt1OdLRGXFug+BIG2Toy1NTMj2Hn8Za0R9XtrppFHWVJt9FQXPgcFVyayWYm9OCcsM PEGwaaquck/doGz1pRNRqbyyEn0x2vU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5AAC461335; Thu, 20 Feb 2025 09:25:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88813C4CEDD; Thu, 20 Feb 2025 09:25:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740043535; bh=YuJNXtZCXILioP9EXJtk+zQDJ5xX29DwjrkwVkabOuk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eHfDlng0v8Yg0eXT66mUNrKorrRhMYZnG/RFBqsPgOxSDJmURY8ClwYt0U8VMgLmx /lHxc1hOIAAOClTuCD9Zq9ALAt7BkIfD3q78BKq51Q6CGnd1w9tAchJNOK2AbUzj0B Z+fq1rMydQJo+Hyw1ma9dmQ5GqC88sS9TuR93CjqYqmYnYpk1etAbxNCqb1u9i+Fmw 8XyHQjSlLx2BAWXbqwK+LREuxPGMRwpvkxgfOcH4TQACbrTvESbEs9q1tRaCNd3s7e bo/Vf1+a8kxNWPCRNPqyfLjLPSDPRjmitdLgtGwL+yRhgsdA8VGsUeS9kRv+gnYl4g bpouRf+0qr3BQ== Date: Thu, 20 Feb 2025 18:25:32 +0900 From: Masami Hiramatsu (Google) To: Sergey Senozhatsky Cc: Waiman Long , Masami Hiramatsu , Steven Rostedt , Peter Zijlstra , Ingo Molnar , Will Deacon , Andrew Morton , Boqun Feng , Joel Granados , Anna Schumaker , Lance Yang , Kent Overstreet , Yongliang Gao , Tomasz Figa , linux-kernel@vger.kernel.org, Linux Memory Management List Subject: Re: [PATCH 1/2] hung_task: Show the blocker task if the task is hung on mutex Message-Id: <20250220182532.fe70e64c79670c70d0af58ec@kernel.org> In-Reply-To: <20250220-112040-neomutt-senozhatsky@chromium.org> References: <173997003868.2137198.9462617208992136056.stgit@mhiramat.tok.corp.google.com> <173997004932.2137198.7959507113210521328.stgit@mhiramat.tok.corp.google.com> <20250219112308.5d905680@gandalf.local.home> <0fa9dd8e-2d83-487e-bfb1-1f5d20cd9fe6@redhat.com> <20250219152435.35077ac3@gandalf.local.home> <20250220080908.fc1494f0f7c611b48fbe0f8b@kernel.org> <20250220-112040-neomutt-senozhatsky@chromium.org> <524bd2b9-5322-4012-b1d0-b76edb84ec4f@redhat.com> <20250220-112040-neomutt-senozhatsky@chromium.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D6B00C000E X-Stat-Signature: rcsczqzwg47tm8pdy75gzs68m9g16jk7 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740043536-35510 X-HE-Meta: U2FsdGVkX19OLmgutyyEZlggX6qtGy9RpHBm7ax9gnxkh4axJn2hLnv7gArucVez6YtLkdlMT0r/Wy7c4uq/LVLbpH3tAXnUjzAd38i+O+r038zK3NbvuqTyGVg5fBPFBTrWayWCBtsO/iYgRi1VlYK0FJfjsnfgmxliAeStCRH3crRSMCKM73/VLJmGU+NlkDbcwkWnFNPL6wwEjx8WIcGrOwOygpjgxwxLLz2+8CF9hQG2sFbQZ/VmVkf/Ptf0vqWS6I0hJUDWqH/HFJscbqeVdM8OlE6R4phEUnLlkawwdGo9ez+iupM7FmQ0cSS9EM+Qfsxt73tEbmULMHyCID3dmi0CJEngyYK/L1WxPJ1wMQSFDfD2KH+bYHqxvmAGVkDnRBb3tjN4YmQG4FpCw+h8z374zsDegMHq5amJrkY7+RPNaFPnWT86AZphfUBj3S3eH46kLVezA7oRgms7BB+3LJsB5hMZgsir2Zlgo+PfTH9XZt6jRvj0StaihGa7+RZZ09GcP9NC97bDcKhjQ6XuFeidJXVLEGimmWOerd2f85IVZdX26wL8isTuCI+n+oboeaNI1eoT4OcExv/SpVFoTN/6IeuRb6XS8+ILooZQAJsiUJu2FgMzoGuXbAXCiwc76Xtfz7/yn+/cd6cQpTN7k3Ulh0G9E1yvyMu4BVyq+v36kL196GzkDpFN4sseCTF+IyTmsooG1MF8WHRy3FFwg0OixoF//fAmOTS4OHo59YAwz0LLVeeBVCLQUBUbfuj4q9oSs73y99Tmv1OOaOBFCcn+QMDF6d6+4uYeoutb1it43Osd2b67BXb6SuwDjsGEWGAU+FfDYtxZiJlfKpm2wRK8qhXK+KI4lxqOPd9qzXD7+TqSOcg0TgDKMnGJRW/fV6zeqCz7ezuXJ9oUbKV4HlP0d29KOHXsGBOOqnQk8u7swXI44+FGV/OXiMN4pWkjTj/M+7uMeiaccoe bX9oc6hk 6a4z/a3wM6IqE85K/hHEdo+C0So3BH06dUqF6XCTIiT+6vs6EqCzCONvh3jH1qnTDMvD4fO8ffQgNSA66a2UnXiOPzEBF3TBeHwPw/ddQC1DoqtpL7x6+0oqZHKfMIkchSevEH/L9b8LN08tvUI2AloJ9PxZ49x81J9HHRdoFS2aDWmL7Ka8quH8HawWyOGqBy6PpIOfbPCRjYdPoF4rt3/8OkMRtdxol/H6BWwHTmYMhROc2eg0Nlg60ZOwaa+gHGuhAKiDZsswFpguD8rhntF1AASOJDrBitK3acxabdQKLFQo4Ib3Rx1ofObW5gMlHqPRbkzdviR4A1+MjRqJgkR9Vd+kZ95Q7hzBzDylpHURC3B+Sr8YSAwdK40Cah4a2NFAulDLng5oaAW5qjRvNNyYUNzpS1KcrQfaR X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 20 Feb 2025 13:19:46 +0900 Sergey Senozhatsky wrote: > On (25/02/19 22:49), Waiman Long wrote: > > On 2/19/25 9:45 PM, Sergey Senozhatsky wrote: > > > On (25/02/20 08:09), Masami Hiramatsu wrote: > > > > So something like this? > > > > > > > > unsigned int block_flags; > > > > union { > > > > struct mutex *mutex; > > > > struct rwsem +rwsem; > > > > struct rtmutex *rtmutex; > > > > } blocked_on; > > > > > > > > enum { > > > > BLOCKED_ON_MUTEX; > > > > BLOCKED_ON_RWSEM; > > > > BLOCKED_ON_RTMUTEX; > > > > BLOCKED_ON_IO; > > > > } block_reason; > > > I totally like this and always wanted to have something simlar, > > > something for all "sleepable" synchronization primitives, lightweight > > > enough (memory and CPU usage wise) to run on consumer devices. I was > > > thinking of a rhashtable where each entry represents "sleepable" > > > primitive with a "owner" pointer and a list of "blocked on" tasks. > > > But I'm sure you'll have a better idea. > > > > > > If I may add a couple of "wishes", can we also add: > > > - completions (so that things like wait_for_completion and > > > synchronize srcu get covered) > > > - wait on bit (so that things like lock_buffer and so on get covered) > > > > Bit lock doesn't have a owner field to track the owning task. > > Right, so that's why I was thinking about keeping it outside in > a hashtable. A list of owners plus a list of blocked_on per "lock", > be it a rwsem, or a mutex, or a bit. Hmm, how can we sync the accesses of the hashtable? We may need spinlocks for the hashtable or use RCU list. If we use the RCU, we may need to allocate RCU object for each time when a lock contention happens (and use kfree_rcu() for each object). Maybe it is better using a spinlock for each hashtable entry but it still introduce overhead (need to check). Thank you, -- Masami Hiramatsu (Google)