Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759895AbeAIR1s (ORCPT + 1 other); Tue, 9 Jan 2018 12:27:48 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:34543 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbeAIR1q (ORCPT ); Tue, 9 Jan 2018 12:27:46 -0500 X-Google-Smtp-Source: ACJfBovqMaZeuJ2pRmRp9PFkDVIPMsfeHamb4Rgt5eFQDzxNYJSluOaz9ANraPw0VGVPHXBp4KdT1FiMDRCMI/8ljzg= MIME-Version: 1.0 In-Reply-To: References: <20180107090336.03826df2@vento.lan> <20180108074324.3c153189@vento.lan> <20180108223109.66c91554@redhat.com> <20180108214427.GT29822@worktop.programming.kicks-ass.net> <20180108231656.3bbd1968@redhat.com> From: Eric Dumazet Date: Tue, 9 Jan 2018 09:27:43 -0800 Message-ID: Subject: Re: Re: dvb usb issues since kernel 4.9 To: Josef Griebichler Cc: Jesper Dangaard Brouer , Peter Zijlstra , Mauro Carvalho Chehab , Alan Stern , Greg Kroah-Hartman , linux-usb@vger.kernel.org, Rik van Riel , Paolo Abeni , Hannes Frederic Sowa , linux-kernel , netdev , Jonathan Corbet , LMML , David Miller , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler wrote: > Hi Linus, > > your patch works very good for me and others (please see https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). No errors in recordings any more. > The patch was also tested on x86_64 (Revo 3700) with positive effect. > I agree with the forum poster, that there's still an issue when recording and watching livetv at same time. I also get audio dropouts and audio is out of sync. > According to user smp kernel 4.9.73 with your patch on rpi and according to user jahutchi kernel 4.11.12 on x86_64 have no such issues. > I don't know if this dropouts are related to this topic. > > If of any help I could provide perf output on raspberry with libreelec and tvheadend. > Sorry to come late to the party. It seems problem comes from some piece of hardware/driver having some precise timing prereq, and opportunistic use of softirq/tasklet (instead maybe of hard irq handlers ) While it is true that softirq might do the job in most cases, we already have cases where this can be easily defeated, say if one cpu has suddenly to handle multiple sources of interrupts for various devices. NET_RX can easily lock the cpu for 10ms (on HZ=100 builds) So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has shown up multiple times in various 'regressions' simply because it could surface the problem more often. But even if you revert it, you can still make the faulty driver/subsystem misbehave by adding more stress to the cpu handling the IRQ. Note that networking lacks fine control of its softirq processing. Some people found/complained that relying more on ksoftirqd was potentially adding tail latencies. Maybe the answer is to tune the kernel for small latencies at the price of small throughput (situation before the patch) 1) Revert the patch 2) get rid of ksoftirqd since it adds unexpected latencies. 3) Let applications that expect to have high throughput make sure to pin their threads on cpus that are not processing IRQ. (And make sure to not use irqbalance, and setup IRQ cpu affinities)