RE: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue

[David Laight <David.Laight@ACULAB.COM>]

From: Arnd Bergmann
> Sent: 25 May 2022 12:04
> 
> On Wed, May 25, 2022 at 11:24 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Apr 19, 2022 at 11:17 PM Allen Pais <apais@linux.microsoft.com> wrote:
> >
> > > The tasklet is an old API which will be deprecated, workqueue API
> > > cab be used instead of them.
> > >
> > > This patch replaces the tasklet usage in drivers/dma/* with a
> > > simple work.
> > >
> > > Github: https://github.com/KSPP/linux/issues/94
> > >
> > > Signed-off-by: Allen Pais <apais@linux.microsoft.com>
> >
> > Paging Vincent Guittot and Arnd Bergmann on the following question
> > on this patch set:
> >
> > - Will replacing tasklets with workque like this negatively impact the
> >   performance on DMA engine bottom halves?
> 
> I think it will in some cases but not others. The problem I see is that
> the short patch description makes it sound like a trivial conversion of a
> single subsystem, but in reality this interacts with all the drivers using
> DMA engines, including tty/serial, sound, mmc and spi.
> 
> In many cases, the change is an improvement, but I can see a number
> of ways this might go wrong:

If the 'tasklet' API is based on the softint (or similar)
then changing to workqueue will cause serious grief in many cases
unless the workqueue process runs at a high priority.

Currently softint callbacks are usually higher priority than
any task/process.
So on a busy system they almost always run.
(They can get caught out by a need_resched() call and suddenly
be fighting with normal user processes for cpu time.)

As arnd said, I suspect this will break anything using tasklets
to chain together audio or video buffers.
Any process code doing that would need probbaly to run at a
'middling' RT priority.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)