From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E093A3CB44 for ; Tue, 9 Jan 2018 17:34:34 -0500 (EST) Received: by mail-qk0-x229.google.com with SMTP id a8so20619256qkb.8 for ; Tue, 09 Jan 2018 14:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=oJ5DjJZCUtMMC/VyoeAp+WmAP7QaR/v64evdehzB/c8=; b=RDwQidzZ4e2Z63Z3YNNjzR+zlCN7vn4siWRnBJ/oW+EVv2yhnXRJ54WiwphPcbK9e4 FGcDMrBAAu18x0uSbtc/h9pKbku3/bWGbHOsdwhIxcZVdNgRzFBoBwWNOFgOzJS4n15W aD8HCjNWJIK9KXbTOZNcKojvLc4W/avTZNukxV7a4T7KIQ5o69TX1b8jCUXY6b9uWbRK fGi40nzc+BXpxFZePp4qx3a5ogYtyp7A2aOanWeEKesrj2W1eCTpPdFeHYtv3J9u2qXE SSr1P0vUPwwYJEj4LmFTA43Z8so9PI2BSaUn2lbOEc7J9jwD/6lS45fyV3cnH6lchzQO fb1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=oJ5DjJZCUtMMC/VyoeAp+WmAP7QaR/v64evdehzB/c8=; b=YHMT7xyQKiHtDjiwVUc/HKfNkpWhFjciq+vQIxTT2xMRLaRPvePwdAlO57oM8e1hdM LjIVcMysvajaQIexdc6J1CWZfPPp3Mcq6A1YTL6gFGn+v4nXEWdYT4A9u9dnVSUA49qs 6wGhg72+Hge+DcfcWqM6AdTcv+CPmW+qg2FkLD9ZpAWhgZMh2Td8VFxzVahDZV2l2C6L YuR5lcDeoXznDE5Jct1eJPb6HZDZu8qwbEdUtn+bpagz5wdesLCgByW9cjXdf3KWOjJM aFpfDRJX5g4oT1FgqYl5036po4SikZjNahxbRdW5PH/aOiDnXTqTaAkbmgTArD+edYu6 ltcw== X-Gm-Message-State: AKwxytf3gWFUFYO3I1UMz3Mpk807PjVHyFYUFayRn/89PA8bhvVL29od Ck+g/HVQRyfg1QMv7rdMc6z99phhrij4z4lBo14= X-Google-Smtp-Source: ACJfBovmY9Ynu4ZW1Jf7r2LaPQZcRvYbRhYlG+CvE1llCHUZzNXLlKkL7it5bBs6DJKxvfch0SbdD9Vc0xM9x73JuRc= X-Received: by 10.55.163.131 with SMTP id m125mr10100427qke.299.1515537274077; Tue, 09 Jan 2018 14:34:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.148.168 with HTTP; Tue, 9 Jan 2018 14:34:32 -0800 (PST) In-Reply-To: References: <20171217120634.pmmuhdqyqmbkxrvl@gofer.mess.org> <20171217112738.4f3a4f9b@recife.lan> <20180106175420.275e24e7@recife.lan> <20180108175551.wp6thxmiozrz4yp2@gmail.com> From: Dave Taht Date: Tue, 9 Jan 2018 14:34:32 -0800 Message-ID: To: Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Cake] Fwd: dvb usb issues since kernel 4.9 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 22:34:35 -0000 I wish I knew a way to not bottleneck on softirq so much in cake. ---------- Forwarded message ---------- From: Linus Torvalds Date: Mon, Jan 8, 2018 at 10:32 AM Subject: Re: dvb usb issues since kernel 4.9 To: Ingo Molnar Cc: Mauro Carvalho Chehab , Josef Griebichler , Greg Kroah-Hartman , Alan Stern , USB list , Eric Dumazet , Rik van Riel , Paolo Abeni , Hannes Frederic Sowa , Jesper Dangaard Brouer , linux-kernel , netdev , Jonathan Corbet , LMML , Peter Zijlstra , David Miller On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar wrote: > > as I doubt we have enough time to root-case this properly. Well, it's not like this is a new issue, and we don't have to get it fixed for 4.15. It's been around since 4.9, it's not a "have to suddenly fix it this week" issue. I just think that people should plan on having to maybe revert it and mark the revert for stable. But if the USB or DVB layers can instead just make the packet queue a bit deeper and not react so badly to the latency of a single softirq, that would obviously be a good thing in general, and maybe fix this issue. So I'm not saying that the revert is inevitable either. But I have to say that that commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") was a pretty damn big hammer, and entirely ignored the "softirqs can have latency concerns" issue. So I do feel like the UDP packet storm thing might want a somewhat more directed fix than that huge hammer of trying to move softirqs aggressively into the softirq thread. This is not that different from threaded irqs. And while you can set the "thread every irq" flag, that would be largely insane to do by default and in general. So instead, people do it either for specific irqs (ie "request_threaded_irq()") or they have a way to opt out of it (IRQF_NO_THREAD). I _suspect_ that the softirq thing really just wants the same thing. Have the networking case maybe set the "prefer threaded" flag just for networking, if it's less latency-sensitive for softirq handling than In fact, even for networking, there are separate TX/RX softirqs, maybe networking would only set it for the RX case? Or maybe even trigger it only for cases where things queue up and it goes into a "polling mode" (like NAPI already does). Of course, I don't even know _which_ softirq it is that the DVB case has issues with. Maybe it's the same NET_RX case? But looking at that offending commit, I do note (for example), that we literally have things like tasklet[_hi]_schedule() that might have been explicitly expected to just run the tasklet at a fairly low latency (maybe instead of a workqueue exactly because it doesn't need to sleep and wants lower latency). So saying "just because softirqd is possibly already woken up, let's delay all those tasklets etc" does really seem very wrong to me. Can somebody tell which softirq it is that dvb/usb cares about? Linus --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619