Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1049043imm; Fri, 15 Jun 2018 10:19:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIP0pYvVjXVrYFTF40yYUqc5z8yBf1OQwGdf1thzI0g2WdrFtICRZszrn6ErPVwrw3cD6Xs X-Received: by 2002:a63:a553:: with SMTP id r19-v6mr2391349pgu.147.1529083174240; Fri, 15 Jun 2018 10:19:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529083174; cv=none; d=google.com; s=arc-20160816; b=oxtkEdmNhEM7sD0AyOu18KYtHfyoeGZmT4cBHpegvp5YuRvVDEnwG3ZgPFdqzACkKn vavdmvEUhqoMaE9ebpqKDdBp3GIAmXLHDnaqiXBO8ykZQDDqaDxJvxCgNyMtdbCQvdge peq9E/bRCBNjmKDcTWWFOfyx4nw6vEIofALBXiX4BL20O0CnOajxlh+w2sUqVi61hw/v AU9jLYrTg6wEoe1pjFDsGNqCljkgOP1iA2HOhDpYrPvmJkirb0AQatwu+zWeJq/DFlmN vShprw1lHwGEO4SruxWyRNBie7JQ7ZSTQWykp1+rweZeCbJLD63ZEfPGLGj8nsi+znMp oK5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=vU/MG2dn1od2KsmomEFmPT3cejL+lGWFxuvPD5ah57k=; b=Azo0PxOjcF+hTWovA9GdFvyAz8yf0P6WzOIVYCQO+88lGBczKtPIW8HnZfPA/aAxNb mGtCYO1mEwgHFCySEG55cFbRgoQTm7QXGHneBKM+onyq3al79lGellAduStvuS3bdqat ohF2cH+WfxNKA2OB5YoxMGwu7O/0M3YDT6TBZZtIgooq1g5FUf/v45j6FqAY3tZIHVmb y088i1zzy+E9rpLVk9CbsEn0ELXw/zsYqlvy+SJXz8+XsqwGC9dKUOTpLZHjP2OEF5IV 8LFczrIWJ5bVUjRBSpV0ZTa6PKnPvzmNwmfc8vKFmJsltYJ9icSQFmn3SYyjaUwGxG5g Yzpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a8-v6si8081018ple.222.2018.06.15.10.19.19; Fri, 15 Jun 2018 10:19:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936371AbeFORRs (ORCPT + 99 others); Fri, 15 Jun 2018 13:17:48 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:46868 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S936136AbeFORRq (ORCPT ); Fri, 15 Jun 2018 13:17:46 -0400 Received: (qmail 4388 invoked by uid 2102); 15 Jun 2018 13:17:45 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jun 2018 13:17:45 -0400 Date: Fri, 15 Jun 2018 13:17:45 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Mikulas Patocka cc: Steven Rostedt , Thomas Gleixner , Ming Lei , Greg Kroah-Hartman , USB list , Kernel development list Subject: High-priority softirqs [was: [PATCH] usb: don't offload isochronous urb completions to ksoftirq] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Jun 2018, Mikulas Patocka wrote: > I think the major problem (in the upstream kernel) with softirq latency is > this: > static inline void invoke_softirq(void) > { > if (ksoftirqd_running()) > return; > > It means that if any piece of code kicks ksoftirq, no tasklets are > processed in the irq context at all. > > So, the ehci callbacks will be offloaded to ksoftirqd (no matter how small > they are) and this causes audio skipping. Could this be changed, so that > it processes tasklets submitted with "tasklet_hi_schedule" in irq context > even if ksoftirqd is running? That's a great question. Basically you're asking to have the HI softirq always handled in the bottom half, never in ksoftirqd, right? Or maybe to have more than one softirq thread, to handle different softirq levels, so that they can be assigned differing priorities. > It's not easy - __do_softirq lacks any locking - so it can't run > concurrently in process context and in irq context. I have no idea. Maybe someone with a better understanding of this part of the kernel can help. Alan Stern