Received: by 10.223.148.5 with SMTP id 5csp6450524wrq; Wed, 17 Jan 2018 14:01:27 -0800 (PST) X-Google-Smtp-Source: ACJfBost7tthodE7U4ZB9jiEOp+mkYHqzzR1ZuMiDL90yAGJw6qqPcWq0edsJ57uXpazvVz2vyy8 X-Received: by 10.159.208.11 with SMTP id a11mr15156609plp.249.1516226487374; Wed, 17 Jan 2018 14:01:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516226487; cv=none; d=google.com; s=arc-20160816; b=IXidBkTKj9FGIcb40RQtqT0Gtu8zVOacpi2Cj+dQOaujDs/6giQxNEWRv2SUoPQOjt wJd419iebfcLECrP9C8dmGLp61LoUN5xFjcs2FTDUWeBfT9vRebrsL4nwMw85QEXRO2V /DsCMPHezKGu2thMrKoLwgNTNsRP37g4yIW8CVXho9pWqtgkP3z7w/n7XanrRnnPv7/J j2Cz5KHclh8Y3i1ucu97fh9zryqkKunhg98PIxg07mVU0WN++5mxmeVKtrUeDSmINlKY d2OFsQg8U8xoTKdtylt5Rh4RVzLIoepRuK/Au5UBHLfDFXC+DeFhZ8OkAm8oKAscK9lG fOBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=7tGuBr2G6A5KGgQpETao3Py++Kq0gJPjcquuxTqsLeQ=; b=M4jZBw1rvhPEnWWYeUtp35GZ3x3w4p6LJMau6a3pmoyh7mPKyNyGJLN4m30izAojdi Z9uS8DOM+Q1ZGgjFaV3miFQ/IhoqRxkdwXhMClilYKJ7cqc9cLhfhqc1VoStZoKEKOoW 6os5w/4RSJH9ePUURihlo2b1d02o+c6wlblgBwc/865yKsFnqeP4aPd/YVmgUTGNJGE0 uoMD2uXtXn4bx+9D09Q140d64lQaWya586iGoWUKyuqUjxz/UOGvtCCql1RxrwihasWN +ratRKoozmERpz5AwjVbNxFQAtmYix2azeFf7GTn0FFA/2DD9SdAFcDg3/tELWddni1U 0w+g== 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 s59si5389966plb.751.2018.01.17.14.01.12; Wed, 17 Jan 2018 14:01:27 -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 S1753628AbeAQWAp (ORCPT + 99 others); Wed, 17 Jan 2018 17:00:45 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:47512 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753075AbeAQWAo (ORCPT ); Wed, 17 Jan 2018 17:00:44 -0500 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ebvii-0001Vj-R1; Wed, 17 Jan 2018 22:58:09 +0100 Date: Wed, 17 Jan 2018 23:00:37 +0100 (CET) From: Thomas Gleixner To: Linus Torvalds cc: David Miller , Mike Galbraith , Peter Zijlstra , Eric Dumazet , Dmitry Safonov , Frederic Weisbecker , Linux Kernel Mailing List , Dmitry Safonov <0x7f454c46@gmail.com>, Andrew Morton , Frederic Weisbecker , Hannes Frederic Sowa , Ingo Molnar , Sasha Levin , Paolo Abeni , Paul McKenney , Radu Rendec , Rik van Riel , Stanislaw Gruszka , Wanpeng Li Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context In-Reply-To: Message-ID: References: <1515782670.7007.3.camel@gmx.de> <20180117.153049.1803664333084879932.davem@davemloft.net> <20180117.164932.1269304606476934540.davem@davemloft.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 17 Jan 2018, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 1:54 PM, Thomas Gleixner wrote: > > raise_softirq() -> raise_softirq_irqoff() > > > > set_softirq_bit(); > > > > if (!in_interrupt()) > > wake_softirqd(); > > > > So if the caller is not in hard or soft interrupt context, which includes > > bottom half disabled regions softirqd is woken. > > That does seem unnecessarily expensive, and maybe we could just do it > with thread flag (TIF_NOTIFY_RESUME or whatever). > > In fact, that was what I *thought* we did. Maybe I just remember some > historical behavior. > > Since networking seems to largely prefer softirqd anyway, maybe that > wake_softirqd() is the right thing to do anyway. Well, but we only do it when we are not in a bh disabled region. The places where thread context raises the network softirqs is usually inside a bh disabled region, so the softirq is executed on local_bh_enable(). The thread is woken up rarely. Thanks, tglx