lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 May 2022 15:14:55 +0000 From: David Laight <David.Laight@...LAB.COM> To: 'Arnd Bergmann' <arnd@...db.de>, Linus Walleij <linus.walleij@...aro.org> CC: Allen Pais <apais@...ux.microsoft.com>, Vincent Guittot <vincent.guittot@...aro.org>, "olivier.dautricourt@...lia.com" <olivier.dautricourt@...lia.com>, Stefan Roese <sr@...x.de>, Vinod Koul <vkoul@...nel.org>, Kees Cook <keescook@...omium.org>, "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>, "Ludovic Desroches" <ludovic.desroches@...rochip.com>, Tudor Ambarus <tudor.ambarus@...rochip.com>, Florian Fainelli <f.fainelli@...il.com>, "Ray Jui" <rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>, "Nicolas Saenz Julienne" <nsaenz@...nel.org>, Paul Cercueil <paul@...pouillou.net>, "Eugeniy.Paltsev@...opsys.com" <Eugeniy.Paltsev@...opsys.com>, "Gustavo Pimentel" <gustavo.pimentel@...opsys.com>, Viresh Kumar <vireshk@...nel.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Leo Li <leoyang.li@....com>, "zw@...kernel.org" <zw@...kernel.org>, Zhou Wang <wangzhou1@...ilicon.com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Sean Wang <sean.wang@...iatek.com>, "Matthias Brugger" <matthias.bgg@...il.com>, Andreas Färber <afaerber@...e.de>, Manivannan Sadhasivam <mani@...nel.org>, Logan Gunthorpe <logang@...tatee.com>, Sanjay R Mehta <sanju.mehta@....com>, Daniel Mack <daniel@...que.org>, Haojian Zhuang <haojian.zhuang@...il.com>, "Robert Jarzmik" <robert.jarzmik@...e.fr>, Andy Gross <agross@...nel.org>, "Bjorn Andersson" <bjorn.andersson@...aro.org>, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, "green.wan@...ive.com" <green.wan@...ive.com>, Orson Zhai <orsonzhai@...il.com>, Baolin Wang <baolin.wang7@...il.com>, Lyra Zhang <zhang.lyra@...il.com>, Patrice CHOTARD <patrice.chotard@...s.st.com>, Chen-Yu Tsai <wens@...e.org>, Jernej Škrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: RE: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue From: Arnd Bergmann > Sent: 25 May 2022 12:04 > > On Wed, May 25, 2022 at 11:24 AM Linus Walleij <linus.walleij@...aro.org> wrote: > > On Tue, Apr 19, 2022 at 11:17 PM Allen Pais <apais@...ux.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@...ux.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)
Powered by blists - more mailing lists