From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 736F4C43142 for ; Tue, 26 Jun 2018 17:08:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C8F02148D for ; Tue, 26 Jun 2018 17:08:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="l2ueCInC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C8F02148D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753128AbeFZRIi (ORCPT ); Tue, 26 Jun 2018 13:08:38 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:54622 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752356AbeFZRIh (ORCPT ); Tue, 26 Jun 2018 13:08:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8hItIRQQzbbLUQjCv/lUubMb9W0h5fXRYBA4xDBqBYY=; b=l2ueCInCohDLJXGx2GMTkIDhz BSci5VIoNAj5hzdrIL9F9n3se3E9+x1cdD1M9yNIEYZ9UpZih/rLYBqcicJzM20VKu/MM7Wslhwg7 8bFZje+AaSvyRSgBR8s9MKkGgWHi1UhXbnG+A/9wt6thXdvBKF3y19f1j6y7MVgcdtC44pKvCKuuJ dI40Ef3awx4AlvSNyf9PXptf7YJnxrxhZ70nbDj2zlzzRThsUBgerd0dMMyjZBgRL6N5fGeTJLr4B HosdBGY3YuCYlUnZgjFq0tzs8uyUbsiyAxzNUDIJt+nYM/zTKoWh1f7MH1xjmcDlYZUdARniOGiF2 vIbh4HhJg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fXrRt-0004pp-V2; Tue, 26 Jun 2018 17:08:14 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 4DE532029F1D7; Tue, 26 Jun 2018 19:08:12 +0200 (CEST) Date: Tue, 26 Jun 2018 19:08:12 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org Subject: Re: [PATCH tip/core/rcu 06/27] rcu: Mark task as .need_qs less aggressively Message-ID: <20180626170812.GH2494@hirez.programming.kicks-ass.net> References: <20180626003448.GA26209@linux.vnet.ibm.com> <20180626003513.27812-6-paulmck@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180626003513.27812-6-paulmck@linux.vnet.ibm.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 25, 2018 at 05:34:52PM -0700, Paul E. McKenney wrote: > If any scheduling-clock interrupt interrupts an RCU-preempt read-side > critical section, the interrupted task's ->rcu_read_unlock_special.b.need_qs > field is set. This causes the outermost rcu_read_unlock() to incur the > extra overhead of calling into rcu_read_unlock_special(). This commit > reduces that overhead by setting ->rcu_read_unlock_special.b.need_qs only > if the grace period has been in effect for more than one second. Even less agressive is never setting it at all. Changelog fails to explain why not setting it every tick is correct, nor why 1s is a 'safe' value to use.