Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965013AbeAJDDe convert rfc822-to-8bit (ORCPT + 1 other); Tue, 9 Jan 2018 22:03:34 -0500 Received: from mout.gmx.net ([212.227.17.22]:58950 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbeAJDDc (ORCPT ); Tue, 9 Jan 2018 22:03:32 -0500 Message-ID: <1515553368.8252.5.camel@gmx.de> Subject: Re: dvb usb issues since kernel 4.9 From: Mike Galbraith To: Jesper Dangaard Brouer , Mauro Carvalho Chehab Cc: Linus Torvalds , Peter Zijlstra , Alan Stern , Ingo Molnar , Josef Griebichler , Greg Kroah-Hartman , USB list , Eric Dumazet , Rik van Riel , Paolo Abeni , Hannes Frederic Sowa , linux-kernel , netdev , Jonathan Corbet , LMML , David Miller Date: Wed, 10 Jan 2018 04:02:48 +0100 In-Reply-To: <20180109222604.64d4377c@redhat.com> References: <20180109154235.2a42f0a0@vento.lan> <20180109222604.64d4377c@redhat.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:XZhGMrAfUTU9Q7xzWv6Lp5A1CuQq9PTM7ea8aob5LSvXDfMGBYm WBFz+IF5m3U7zdbmkxz7cGLQLUQD8Hcnb3B5Ikgbtjl2MCNs2NZEzdVdcR62KqCbIJriOVr W/OcO6lwv2B7kP1326gOOlAI9G0eSne0ax6+2uzfZMyItxIXlvbXRMQ/usLiqnPKd1CbkD5 BXNuhcLnbAO/VxstQcbYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:zevO+JJ7ZzQ=:RlfLtZMK15jw/0OhBmUq3i Uf5GA5KFEF8ioeiTaRqb5wrntA+vNnNKO6FCyd5s2h4ie8c2UVqWSI+7HPUekHH7BhQ1olE1y 4/l5X2TVNuPBao5/MmxP0YDTHDFyMISYp/PiUuijT+DroLwFVboxTHolxTgVUolR7NYCfg7Ny M2rYDLfT/5NyhX1+OyxYVs/8TwE4vbJ9/J4yHdd6WYk3EKQNhDLDkG1UakSovkcZwuwkY9VNu Ag7K1KNPZZie1zkoALzur4cmRQ1X8vn8XpbhCHTMn8YZXEFWnm8eRiTX0elixgqAwVXY5S/Nd ftSPP+Vhm7mu2s/xLzdmM29jmK5wMmT6nrayR18df0yCRNEjnnlhiMX+RLBHAU2v5sDEL9OUS bIRZifoTNOk27qB1LuNywFCxqVJ5j2KBwvgfh2MyCuqXeFybmeUYKvXrllJux/oSHFx22+OxL 7p2LuzMX/L7+4hDv5zzsY9VRDMBXpOKeK+zSfVrsBvO8vsIftdKmaHnqaAxoYRDP5Rg+TvXau rYO+JD25W7UVEJJVq+mJhHY6lUfp3OZjFozEWhFBEFdHQiUToCK99kqCCVyErhH/H8zfZWdea L2uKdCjZdnomTrMsiq2iPs9tUhhKqp45axKCANY7qRa9lTOZN763oqNF7OIVd/PB4AecJt+al ue0YeEfkmlWPGo/2vYpSykeTwNaEc9Qx34xk+3n9Is7+Yt0LTVX4BtFTgC4eBQt+OcFPnRwYu grwZQ+pcHIx+RXVkJLDJoRul5BXl9DdOeHatmUPoODqfR4X/o4tMGOUovsub4aHMnBBmTymK9 LGCgAuZMhhxXpMkyn1l98u3fkhOWlPOnvoE1HHpMvCoNuxzhHw= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, 2018-01-09 at 22:26 +0100, Jesper Dangaard Brouer wrote: > > I've previously experienced that you can be affected by the scheduler > granularity, which is adjustable (with CONFIG_SCHED_DEBUG=y): > > $ grep -H . /proc/sys/kernel/sched_*_granularity_ns > /proc/sys/kernel/sched_min_granularity_ns:2250000 > /proc/sys/kernel/sched_wakeup_granularity_ns:3000000 > > The above numbers were confirmed on the RPi2 (see[2]). With commit > 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), I expect/assume that > softirq processing latency is bounded by the sched_wakeup_granularity_ns, > which with 3 ms is not good enough for their use-case. Note of caution wrt twiddling?sched_wakeup_granularity_ns: it must remain < sched_latency_ns/2 else you effectively disable wakeup preemption completely, turning CFS into a tick granularity scheduler. -Mike