[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZbkayGEYJNJx3ohw@slm.duckdns.org>
Date: Tue, 30 Jan 2024 05:50:32 -1000
From: Tejun Heo <tj@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: torvalds@...ux-foundation.org, mpatocka@...hat.com,
linux-kernel@...r.kernel.org, dm-devel@...ts.linux.dev,
msnitzer@...hat.com, ignat@...udflare.com, damien.lemoal@....com,
bob.liu@...cle.com, houtao1@...wei.com, peterz@...radead.org,
mingo@...nel.org, netdev@...r.kernel.org, allen.lkml@...il.com,
kernel-team@...a.com, tglx@...utronix.de
Subject: Re: [PATCHSET wq/for-6.9] workqueue: Implement BH workqueue and
convert several tasklet users
Hello, Sebastian.
On Tue, Jan 30, 2024 at 11:20:11AM +0100, Sebastian Andrzej Siewior wrote:
> If one context creates multiple work item which are then moved to
> tasklet I don't see the difference vs workqueue with a bh_disable()
> around it.
The main difference is that it avoids scheduling latencies in scenarios
where softirq isn't heavily loaded.
> Looking at the USB changes, I would prefer to see it converted to
> threaded interrupts instead of using tasklet or workqueue. Both
> approaches (current tasklet, suggested workqueue) lose the original
> context where the request was created. Having threaded interrupts would
> allow to keep everything in the same "context" so you could prioritize
> according to your needs.
That's great. If threaded IRQs or even regular workqueues are suitable, that
should be fine. This conversion is just targeted at the use cases which can
benefit from executing in the softirq context.
Thanks.
--
tejun
Powered by blists - more mailing lists