From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756737AbcB2E6P (ORCPT ); Sun, 28 Feb 2016 23:58:15 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37702 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755501AbcB2E6N (ORCPT ); Sun, 28 Feb 2016 23:58:13 -0500 Message-ID: <1456721889.3488.67.camel@gmail.com> Subject: Re: Softirq priority inversion from "softirq: reduce latencies" From: Mike Galbraith To: Francois Romieu Cc: Peter Hurley , Eric Dumazet , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Greg KH , dmaengine@vger.kernel.org, John Ogness , Sebastian Andrzej Siewior , Andrew Morton Date: Mon, 29 Feb 2016 05:58:09 +0100 In-Reply-To: <20160228170109.GA16322@electric-eye.fr.zoreil.com> References: <56D1E8B6.6090003@hurleysoftware.com> <1456638957.3676.12.camel@gmail.com> <20160228170109.GA16322@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2016-02-28 at 18:01 +0100, Francois Romieu wrote: > Mike Galbraith : > [...] > > Hrm, relatively new + tasklet woes rings a bell. Ah, that.. > > > > > > What's worse is that at the point where this code was written it was > > already well known that tasklets are a steaming pile of crap and > > should die. > > > > > > Source thereof https://lwn.net/Articles/588457/ > > tasklets are ingrained in the dmaengine API (see Documentation/dmaengine/client.txt > and drivers/dma/virt-dma.h::vchan_cookie_complete). > > Moving everything to irq context or handling his own sub-{jiffy/ms} timer > while losing async dma doesn't exactly smell like roses either. :o( https://lwn.net/Articles/239633/ If I'm listening properly, the root cause is that there is a timing constraint involved, which is being exposed because one softirq raises another (ew). Processing timeout happens, freshly raised tasklet wanders off to SCHED_NORMAL kthread context where its constraint dies. Given the dma stuff apparently works fine in -rt (or did, see below), timing constraints can't be super tight, so perhaps we could grow realtime workqueue support for the truly deserving. The tricky bit would be being keeping everybody and his brother from abusing it. WRT -rt: if dma tasklets really do have hard (ish) constraints, -rt recently "broke" in the same way.. of all softirqs which are deferred to kthread context, due to a recent change, only timer/hrtimer are executed at realtime priority by default. -Mike