linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Waiman Long <llong@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Joel Granados <joel.granados@kernel.org>,
	Anna Schumaker <anna.schumaker@oracle.com>,
	Lance Yang <ioworker0@gmail.com>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	Yongliang Gao <leonylgao@tencent.com>,
	Tomasz Figa <tfiga@chromium.org>,
	linux-kernel@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] hung_task: Show the blocker task if the task is hung on mutex
Date: Thu, 20 Feb 2025 18:25:32 +0900	[thread overview]
Message-ID: <20250220182532.fe70e64c79670c70d0af58ec@kernel.org> (raw)
In-Reply-To: <20250220-112040-neomutt-senozhatsky@chromium.org>

On Thu, 20 Feb 2025 13:19:46 +0900
Sergey Senozhatsky <senozhatsky@chromium.org> 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) <mhiramat@kernel.org>


      parent reply	other threads:[~2025-02-20  9:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <173997003868.2137198.9462617208992136056.stgit@mhiramat.tok.corp.google.com>
2025-02-19 13:33 ` [PATCH 0/2] hung_task: Dump the blocking task stacktrace Lance Yang
2025-02-19 15:02   ` Lance Yang
2025-02-19 20:20     ` Waiman Long
2025-02-20  1:27       ` Lance Yang
2025-02-20 14:18       ` Masami Hiramatsu
2025-02-20 14:22         ` Waiman Long
     [not found] ` <173997004932.2137198.7959507113210521328.stgit@mhiramat.tok.corp.google.com>
2025-02-19 16:23   ` [PATCH 1/2] hung_task: Show the blocker task if the task is hung on mutex Steven Rostedt
2025-02-19 20:18     ` Waiman Long
2025-02-19 20:24       ` Steven Rostedt
2025-02-19 22:44         ` Waiman Long
2025-02-19 22:56           ` Masami Hiramatsu
2025-02-19 23:55             ` Steven Rostedt
2025-02-20  1:52               ` Lance Yang
2025-02-20  2:07               ` Masami Hiramatsu
2025-02-20  2:21                 ` Waiman Long
2025-02-20  2:23                 ` Steven Rostedt
2025-02-20  1:36             ` Waiman Long
2025-02-20  1:41               ` Steven Rostedt
2025-02-20  2:15                 ` Waiman Long
2025-02-20  2:27                   ` Steven Rostedt
2025-02-20  3:29                     ` Waiman Long
2025-02-20  2:59                   ` Masami Hiramatsu
2025-02-20  3:37                     ` Waiman Long
2025-02-20  9:29                       ` Masami Hiramatsu
2025-02-20 13:28                         ` Waiman Long
2025-02-20  2:40                 ` Masami Hiramatsu
2025-02-20  3:11                   ` Steven Rostedt
2025-02-20 13:13                     ` Waiman Long
2025-02-20 16:30                       ` Steven Rostedt
2025-02-19 23:09         ` Masami Hiramatsu
2025-02-19 23:58           ` Steven Rostedt
2025-02-20  2:08             ` Masami Hiramatsu
2025-02-20  2:25               ` Waiman Long
2025-02-20  1:40           ` Waiman Long
2025-02-20  2:45           ` Sergey Senozhatsky
2025-02-20  3:46             ` Sergey Senozhatsky
2025-02-20  3:49             ` Waiman Long
2025-02-20  4:19               ` Sergey Senozhatsky
2025-02-20  9:25               ` Masami Hiramatsu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250220182532.fe70e64c79670c70d0af58ec@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anna.schumaker@oracle.com \
    --cc=boqun.feng@gmail.com \
    --cc=ioworker0@gmail.com \
    --cc=joel.granados@kernel.org \
    --cc=kent.overstreet@linux.dev \
    --cc=leonylgao@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llong@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox