Received: by 10.192.165.148 with SMTP id m20csp239243imm; Fri, 4 May 2018 09:31:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3ceZhGKMl4VpJiOi61tPpguHhZanfMlrr4RkNhr2PJ3ZRR4kYPYPjsyBb39OOjipwHF20 X-Received: by 10.98.194.5 with SMTP id l5mr27446691pfg.6.1525451490124; Fri, 04 May 2018 09:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525451490; cv=none; d=google.com; s=arc-20160816; b=PylobpdbdbAx9JDhLboijpZJ+OOY83iU3tlDQYt8D3Ys0//6vwAujndSJyQJtr0Ezn 55CWZhwq14qHaWEW4M8znYCWzqmBel52LLxUoqb5t8tM7rCybKHNIePESmX5GxzdmF7+ QnL/BfZfty4/9nZ8M0WT6YUuItBMBTAbgJFfSjQ/Udtvzl0qPZZlmFbQPykwdE+A0Lov 5xb1QwDxygXdZRWAqoZA7w5Z/6S5QjKb21YVCBqvK0Jw60HgfIYOBDAUWScu90klb940 u0NPZHJmTXkWYbl5DjqsaqYI3S4WQt3JVFjKgfm6Lllix6VO6uJ6ctCBvp+WqJ1qVsDh fK4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=DdX/QNd2xH4K1TjMM3JmyYACFmez/g4DKvWb9Uw5Y78=; b=JWsFJuSLAFZymgNsis5GEIM+luYJelX9n7zDjPujnCkOoa+qhNHuIU5+7XGWXNqdHZ zCAaCo/KP5WcQ0XkJsooCqeJzllYdwGqNfnH7XLrKRzvKZb5AltF7mS681NA4EDtqI8c NBvsvH7EMYCm+ZI+UkOwPEqNjS60NCdL1cxmUHcFhJHOIJPPAcJwYeWkFVEeSlNdMNxj EmNdzVhGMo/M3Q0yy1UgO3nf3oqJXHfrLPPJYN2R0yWd87Hd63oMgSLzuQiqjC/+yoBQ /am/8teYf0+MJsUuLMSGxu7NULO1W1V3b4oLXHY3EjdTt95BBLzmvV9CdKVMwfpwZqtp gYvg== 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 206si13377053pfw.130.2018.05.04.09.31.15; Fri, 04 May 2018 09:31:30 -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 S1751748AbeEDQaz (ORCPT + 99 others); Fri, 4 May 2018 12:30:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:39120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbeEDQaw (ORCPT ); Fri, 4 May 2018 12:30:52 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B4CAC2176D; Fri, 4 May 2018 16:30:51 +0000 (UTC) Date: Fri, 4 May 2018 12:30:50 -0400 From: Steven Rostedt To: Joel Fernandes Cc: Paul McKenney , Mathieu Desnoyers , LKML Subject: Re: rcu-bh design Message-ID: <20180504123050.2841f80d@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 04 May 2018 16:20:11 +0000 Joel Fernandes wrote: > Hi Paul, everyone, > > I had some question(s) about rcu-bh design. > I am trying to understand the reasoning or need of it. I see that rcu-bh > will disable softirqs across read-side sections. But I am wondering why > this is needed. __do_softirq already disables softirq when a softirq > handler is running. The only reason I can see is, rcu-bh helps in > situations where - a softirq interrupts a preemptible RCU read-section and > prevents that read section from completing. But this problem would happen > if anyone where to use rcu-preempt - then does rcu-preempt even make sense > to use and shouldn't everyone be using rcu-bh? I thought rcu-bh uses softirqs as a quiescent state. Thus, blocking softirqs from happening makes sense. I don't think an rcu_read_lock_bh() makes sense in a softirq. > > The other usecase for rcu-bh seems to be if context-switch is used as a > quiescent state, then softirq flood can prevent that from happening and > cause rcu grace periods from completing. > But preemptible RCU *does not* use context-switch as a quiescent state. It doesn't? > So in that case rcu-bh would make > sense only in a configuration where we're not using preemptible-rcu at all > and are getting flooded by softirqs. Is that the reason rcu-bh needs to > exist? Maybe I'm confused by what you are asking. -- Steve