[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YhUq70Y/tKGGNbR0@slm.duckdns.org>
Date: Tue, 22 Feb 2022 08:26:55 -1000
From: Tejun Heo <tj@...nel.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Haakon Bugge <haakon.bugge@...cle.com>,
syzbot <syzbot+831661966588c802aae9@...kaller.appspotmail.com>,
Jason Gunthorpe <jgg@...pe.ca>,
LKML <linux-kernel@...r.kernel.org>,
OFED mailing list <linux-rdma@...r.kernel.org>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
Lai Jiangshan <jiangshanlai@...il.com>
Subject: Re: [syzbot] possible deadlock in worker_thread
On Tue, Feb 15, 2022 at 09:05:38AM -0800, Bart Van Assche wrote:
> On 2/15/22 04:48, Tetsuo Handa wrote:
> > I do not want to do like
> >
> > - system_wq = alloc_workqueue("events", 0, 0);
> > + system_wq = alloc_workqueue("events", __WQ_SYSTEM_WIDE, 0);
> >
> > because the intent of this change is to ask developers to create their own WQs.
>
> I want more developers to use the system-wide workqueues since that reduces
> memory usage. That matters for embedded devices running Linux.
Each wq is just a frontend interface to backend shard pool and doesn't
consume a lot of memory. The only consumption which would matter is when
WQ_MEM_RECLAIM is specified which creates its dedicated rescuer thread to
guarantee forward progress under memory contention, but we aren't talking
about those here.
Thanks.
--
tejun
Powered by blists - more mailing lists