Received: by 10.223.185.116 with SMTP id b49csp1170022wrg; Fri, 16 Feb 2018 13:48:03 -0800 (PST) X-Google-Smtp-Source: AH8x227iDwFTIN+Ppmx9K9M8+THkSZdJM2PldZEXojh7zf2S53A2LcHtth/3iUOALY0228Q6GDK2 X-Received: by 2002:a17:902:3084:: with SMTP id v4-v6mr7200807plb.131.1518817683788; Fri, 16 Feb 2018 13:48:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518817683; cv=none; d=google.com; s=arc-20160816; b=OSiuZ7eNhbtzvryLRzBoVVBTpXUVkYa6n/1G22C4xYr0tCDxDuurCnHArEyhV96+oh gw0n7MjE12KjVj3eojcHVbtxslF8/qvmnA+HbJQQzMMEom5YdJxvWOgp7ULSYjjl/Ige t5+0uWIZ02OzcdnYaqubCG1wEv/7tavERirEXoWUkazI38dKhRjlzIpVf+1/DpnfV9XS oQV21IDarWZOlfdf29lroBLcQM6LdqK7QMxWUSEp1P6oj6D8Gr/A+vT9PMJ3RrAcRB1W s0FU0GhsKJ0Fhrsm/orYD9Yj7HdSDh29UaCrj4iFT9Jiugg64NPmgYrhHwNKXF4nM94h BIOQ== 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=ynJVgyL+DKHfEq+ShBxLTCwdAPLAoUzEO3eZgYL5Pg4=; b=kNrj1QmmkCLnK8u6UaToUF/Jo6xurmabyxNyi97KttzhdjwiEmUK4vBLO/ts/T55bk qCqNZlRR4i03VGOm6CGv8lpGKRxwdvFHKKQRhp3oawjL68KoYktNfuYZREXNhdSGCGBI 1/G0Ulew9Tun+/sbZpYJCB4h8QTuc9O8OIOc+rFjuTR3qwN5o50MLY9ZF25jEKsBuQZh aJXzuehkGJUt6pxWEM1kwSZsbtb+CC+9CPLat/KDquFr4aM8j+wEDBZp5WRLm08/4yvk dF6QOTJ8F6793Osmd/wpWfeaID6D9kyYPUooEwkvnrR9zEkMyFkYBagGCJbs6yMjyFfh C1vw== 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 70-v6si288881ple.147.2018.02.16.13.47.49; Fri, 16 Feb 2018 13:48:03 -0800 (PST) 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 S1751020AbeBPVqn (ORCPT + 99 others); Fri, 16 Feb 2018 16:46:43 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:54914 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750780AbeBPVqm (ORCPT ); Fri, 16 Feb 2018 16:46:42 -0500 Received: (qmail 6570 invoked by uid 2102); 16 Feb 2018 16:46:41 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Feb 2018 16:46:41 -0500 Date: Fri, 16 Feb 2018 16:46:41 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Sebastian Andrzej Siewior cc: Mauro Carvalho Chehab , Frederic Weisbecker , LKML , Peter Zijlstra , Thomas Gleixner , Subject: Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet In-Reply-To: <20180216203808.23mvv4mtz6khhwfv@linutronix.de> 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, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 13:29:01 [-0500], Alan Stern wrote: > > We originally used tasklets because we didn't want to incur the delays > > associated with running in a process context. It seems odd to be > > reversing that decision now. > > The theaded interrupt runs SCHED_FIFO priority 50 by default. The only > thing that can interrupt it are interrupts, a softirq (not ksoftirqd) > and other tasks with a higher priority than 50. > There should be no downside performance wise. Maybe. It would be nice to see some real measurements. > > > The URBs from the root-hub never create an interrupt so I currently > > > process them in a workqueue (I'm not sure if an URB-enqueue in the > > > completion handler would break something). > > > > It worked okay before we changed over to using tasklets. > > Ah okay. I've seen that HCDs were no longer dropping their internal lock > and I wasn't sure if such a change was also applied in RH-code. Oh... my memory was faulty. After going back and looking at the old source, I see that before we switched to tasklets the code _did_ drop the hcd_root_hub_lock when giving back root-hub URBs. Now it doesn't. (It's also worth noticing that the current code gives back root-hub URBs in a tasklet even for HCDs that don't support using tasklets for non-root-hub URBs.) In any case, latency doesn't matter much for root-hub URBs. Alan Stern