From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 12DD7CD11DD for ; Thu, 28 Mar 2024 22:01:18 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=QQ+Ol01e; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4V5HYS543dz3vtj for ; Fri, 29 Mar 2024 09:01:16 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=QQ+Ol01e; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=vkoul@kernel.org; receiver=lists.ozlabs.org) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4V5Bvr279cz3fQR for ; Fri, 29 Mar 2024 05:31:52 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7250A61783; Thu, 28 Mar 2024 18:31:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9561C433C7; Thu, 28 Mar 2024 18:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711650709; bh=09Kq07Ctu1YK6YAopY47/y5AlbJwjHjNBMXfeYxKY3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QQ+Ol01eGrtbmmXmm5UOF8z3YVrAFzrLyUinoyXQOw2oD/3BtgXxtRpcyL6qEGHMi Fuf1dGmu1+mXVCx0A2v+QG1OZmZa5GwKeTprSp0vXiGl5WvN4w7glf0wb/Ho4jGsI6 A7WhuNfxRZ+SYEDd2EHDavctgY396ec7mZY6h+UmOVbwQhncgmm56Grgtq512eTU0I juRVEJtAyO8mA2/2SAJmqgsMiWvU8lqDqaMAEVDmDUSGgn+tYLJ7mum23hafaIgM0S 0/cB+mlWradcKD4+nkGPqD1rFiy3Q7s73Qm1b4qRq5IHy2lK358t2WVn9s4EqNJkuF qXaWYWlrz6OoQ== Date: Fri, 29 Mar 2024 00:01:43 +0530 From: Vinod Koul To: Arnd Bergmann Subject: Re: [PATCH 2/9] dma: Convert from tasklet to BH workqueue Message-ID: References: <20240327160314.9982-1-apais@linux.microsoft.com> <20240327160314.9982-3-apais@linux.microsoft.com> <2e9257af-c123-406b-a189-eaebeecc1d71@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e9257af-c123-406b-a189-eaebeecc1d71@app.fastmail.com> X-Mailman-Approved-At: Fri, 29 Mar 2024 08:57:06 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: imx@lists.linux.dev, Ulf Hansson , Oliver Neukum , duncan.sands@free.fr, Kunihiko Hayashi , "linux-mmc @ vger . kernel . org" , aubin.constans@microchip.com, Linus Walleij , Frank Li , linux-hyperv@vger.kernel.org, linux-mips@vger.kernel.org, Paul Cercueil , linux-tegra@vger.kernel.org, Netdev , maintainers@bluecherrydvr.com, peter.ujfalusi@gmail.com, Manivannan Sadhasivam , linux-riscv@lists.infradead.org, "K. Y. Srinivasan" , Robert Jarzmik , haijie1@huawei.com, Linux-Renesas , Wei Liu , Linux-OMAP , Florian Fainelli , linux-rdma@vger.kernel.org, Viresh Kumar , Jassi Brar , Dexuan Cui , HaraldWelte@viatech.com, Jernej Skrabec , "jh80.chung" , zw@zh-kernel.org, Chen-Yu Tsai , Alan Stern , linux-arm-msm@vger.kernel.org, Orson Zhai , pierre@ossman.eu, linux-usb@vger.kernel.org, Eugeniy.Paltsev@synopsys.com, Patrice Chotard , asahi@lists.linux.dev, brucechang@via.com.tw, Kees Cook , oakad@yahoo.com, Sven Peter , Ray Jui , Sascha Hauer , Sean Wang , linux-actions@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, Haojian Zhuang , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , dmaengine@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, Baolin Wang , Matthias B rugger , openipmi-developer@lists.sourceforge.net, Mauro Carvalho Chehab , Allen Pais , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Scott Branden , logang@deltatee.com, Bjorn Andersson , Hector Martin , Haiyang Zhang , linux-kernel@vger.kernel.org, Leo Li , Konrad Dybcio , linux-sunxi@lists.linux.dev, Zhou Wang , linux-s390@vger.kernel.org, Masami Hiramatsu , Chunyan Zhang , Tejun Heo , Manuel Lauss , linux-media@vger.kernel.org, Shawn Guo , Andreas =?iso-8859-1?Q?F=E4rber?= , Daniel Mack Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 28-03-24, 11:08, Arnd Bergmann wrote: > On Thu, Mar 28, 2024, at 06:55, Vinod Koul wrote: > > On 27-03-24, 16:03, Allen Pais wrote: > >> The only generic interface to execute asynchronously in the BH context is > >> tasklet; however, it's marked deprecated and has some design flaws. To > >> replace tasklets, BH workqueue support was recently added. A BH workqueue > >> behaves similarly to regular workqueues except that the queued work items > >> are executed in the BH context. > > > > Thanks for conversion, am happy with BH alternative as it helps in > > dmaengine where we need shortest possible time between tasklet and > > interrupt handling to maximize dma performance > > I still feel that we want something different for dmaengine, > at least in the long run. As we have discussed in the past, > the tasklet context in these drivers is what the callbacks > from the dma client device is run in, and a lot of these probably > want something other than tasklet context, e.g. just call > complete() on a client-provided completion structure. > > Instead of open-coding the use of the system_bh_wq in each > dmaengine, how about we start with a custom WQ_BH > specifically for the dmaengine subsystem and wrap them > inside of another interface. > > Since almost every driver associates the tasklet with the > dma_chan, we could go one step further and add the > work_queue structure directly into struct dma_chan, > with the wrapper operating on the dma_chan rather than > the work_queue. I think that is very great idea. having this wrapped in dma_chan would be very good way as well Am not sure if Allen is up for it :-) -- ~Vinod