From: Tejun Heo <tj@kernel.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Doug Nelson <doug.nelson@intel.com>,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
mingo@redhat.com, syzkaller-bugs@googlegroups.com,
x86@kernel.org
Subject: Re: BUG: Stall on adding/removing wokers into workqueue pool
Date: Wed, 30 Oct 2024 13:42:24 -1000 [thread overview]
Message-ID: <ZyLEYMZP2SiVGeSD@slm.duckdns.org> (raw)
In-Reply-To: <1cf7b0dbfa4190eeaf0b3401bf7a991b8db59a59.camel@linux.intel.com>
Hello, Tim.
On Tue, Oct 29, 2024 at 03:03:33PM -0700, Tim Chen wrote:
> Hi Tejun,
>
> Forwarding this task hung seen by my colleague Doug Nelson. He tested
> the 6.12-rc4 kernel with an OLTP workload running on a 2 socket with
> Granite Rapids CPU that has 86 cores per socket. The traces
> seem to indicate that the acquisition
> of wq_pool_attach_mutex stalled in idle_cull_fn() when removing worker from
> the pool. Doug hit this problem occasionally in his tests.
>
> Searching through the bug reports, there's a similar report by szybot on the
> 6.12-rc2 kernel. Szybot reported similar task hung when attaching workers to
> the pool: https://lore.kernel.org/all/6706c4ba.050a0220.1139e6.0008.GAE@google.com/T/
> So we suspect that the problem is not GNR CPU specific.
>
> Wonder if this problem is a known one?
First time I see it. The trace doesn't show who's holding the mutex. There
doesn't seem to be any place where that mutex should leak at least on a
glance, so hopefully it shouldn't be too difficult to find who's holding it.
Can you trigger sysrq-d and sysrq-t and post the output?
Thanks.
--
tejun
next prev parent reply other threads:[~2024-10-30 23:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 22:03 BUG: Stall on adding/removing wokers into workqueue pool Tim Chen
2024-10-30 23:42 ` Tejun Heo [this message]
2024-11-01 17:37 ` Tim Chen
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=ZyLEYMZP2SiVGeSD@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=doug.nelson@intel.com \
--cc=hpa@zytor.com \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.