Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp379145rwb; Sat, 17 Sep 2022 06:56:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5b/3+vvh1aB+m1nZmafjixBcIa2BsQnuDcKlbhRxo1hdn1za0zUHv+8QuFs6ilonmB0Kjv X-Received: by 2002:a05:6402:2201:b0:44f:443e:2a78 with SMTP id cq1-20020a056402220100b0044f443e2a78mr7866170edb.76.1663423007344; Sat, 17 Sep 2022 06:56:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663423007; cv=none; d=google.com; s=arc-20160816; b=EQ/CNSbRY87pMLn3zmHiBsOVbhatAhQQl6ChJFo8UfwHcVMjwg+ya0nTUhVAhXNlau 1mppbPLoNHmjTWH4v5gzkCbgFoxRmtlK8vDqm/DAhVIaJ3RaQbATH3Ufor81m3yXfRFN PZTVPsl4sSuZnIVrDBHSkHf2FNSpg4amz34L4aMceBeGE9zNsNl6h128f6xWknpo6r+C I1dyp2emp5M6oHRqlYKkn6vYZXrhKSgayyYQUPGWSBa8dJftswz+/m3kjdNv+3YaNpgI 4ukTM4sBrxdS/qnHKj7nKx0seXDD8Z4o2okWYRDNwO9Nwlr1nf2LgQPaC0ao/S2cxSLo XBYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=kSVGLwjHHpXADlmgu1J5mJ+LZ5I+HG7t0XI3xSThcYM=; b=kASP6Oh7XU89yHOCsnksI23brZhMT4dDvnkkGVgMuXEw9p/s1bpSTInGPHe/ZWKPOw DHvzcsxeexGKoJw/v6uRJMFZcNLuzz13Hk9SjMB6w1aVuRTPJqF07bmR14MxKN11gCSC eo6WS8A00YVMVBRw/f7mGgFYUBRT9P5TNW0O8LvFBbQ7bLthT00s0idF5mU+9B6LmZmF yzrAHqmA3VLh9O5YboSS4SBLB6+qxgO0qYt4AxmLbb7CDsl4SaSCrLkBVlkh2nWntd0+ tmUpget+/cKgNu2GSF8F5DUfn6XLQw4fQ8dsh4wQGpj7wT3yrvgrm+WuSySeXIE2uAeU 6/8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=q1hYmOby; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p5-20020aa7d305000000b0044eabb548b4si4416339edq.473.2022.09.17.06.56.18; Sat, 17 Sep 2022 06:56:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=q1hYmOby; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229570AbiIQNgC (ORCPT + 99 others); Sat, 17 Sep 2022 09:36:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbiIQNf7 (ORCPT ); Sat, 17 Sep 2022 09:35:59 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51F1F31EE6 for ; Sat, 17 Sep 2022 06:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=kSVGLwjHHpXADlmgu1J5mJ+LZ5I+HG7t0XI3xSThcYM=; b=q1hYmOby16d2al+llIDR8ZWK7F znf4AQoG2fHEflkvkMpNXAWbSg3/T8yLMm6pPEo8btJQ66RHb0xtRK0p4Bi6xuqjk5xpV+HgFjbvZ 69m4TIW5aymgMw0w/SKp3+LVNtKuZ3DHBwjITVC6xPbsDf6qQ3VWkM80VIatm9pGJUJNv6o6ccJb6 rYQ91Q+aHed1IYQ1wmeGazhqheJIccKQ5F8+Vm3qTdFoInEq/s3gDlTeDhMAGUorlNEdQ5g0ORl3f V6Wo4MZvaWEdKHT4IUdEBRjJrKysHVifOSzqcitRInczZ7MTWOJXoVYGVCr8JfhIoIJMgak4gGWKu sdXxf6ww==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZXyv-003Ei1-2n; Sat, 17 Sep 2022 13:35:41 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 5BAEE30013F; Sat, 17 Sep 2022 15:35:32 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3A1FF207EC255; Sat, 17 Sep 2022 15:35:32 +0200 (CEST) Date: Sat, 17 Sep 2022 15:35:32 +0200 From: Peter Zijlstra To: Joel Fernandes Cc: Boqun Feng , Frederic Weisbecker , "Paul E. McKenney" , "Rafael J. Wysocki" , Thomas Gleixner , LKML , Steven Rostedt Subject: Re: RCU vs NOHZ Message-ID: References: <20220915160600.GA246308@paulmck-ThinkPad-P17-Gen-1> <20220915191427.GC246308@paulmck-ThinkPad-P17-Gen-1> <20220916075817.GE246308@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2022 at 02:11:10PM -0400, Joel Fernandes wrote: > Hi Peter, > > On Fri, Sep 16, 2022 at 5:20 AM Peter Zijlstra wrote: > [...] > > > It wasn't enabled for ChromeOS. > > > > > > When fully enabled, it gave them the energy-efficiency advantages Joel > > > described. And then Joel described some additional call_rcu_lazy() > > > changes that provided even better energy efficiency. Though I believe > > > that the application should also be changed to avoid incessantly opening > > > and closing that file while the device is idle, as this would remove > > > -all- RCU work when nearly idle. But some of the other call_rcu_lazy() > > > use cases would likely remain. > > > > So I'm thinking the scheme I outlined gets you most if not all of what > > lazy would get you without having to add the lazy thing. A CPU is never > > refused deep idle when it passes off the callbacks. > > > > The NOHZ thing is a nice hook for 'this-cpu-wants-to-go-idle-long-term' > > and do our utmost bestest to move work away from it. You *want* to break > > affinity at this point. > > > > If you hate on the global, push it to a per rcu_node offload list until > > the whole node is idle and then push it up the next rcu_node level until > > you reach the top. > > > > Then when the top rcu_node is full idle; you can insta progress the QS > > state and run the callbacks and go idle. > > In my opinion the speed brakes have to be applied before the GP and > other threads are even awakened. The issue Android and ChromeOS > observe is that even a single CB queued every few jiffies can cause > work that can be otherwise delayed / batched, to be scheduled in. I am > not sure if your suggestions above address that. Does it? Scheduled how? Is this callbacks doing queue_work() or something? Anyway; the thinking is that by passing off the callbacks on NOHZ, the idle CPUs stay idle. By running the callbacks before going full idle, all work is done and you can stay idle longer. > Try this experiment on your ADL system (for fun). Boot to the login > screen on any distro, All my dev boxes are headless :-) I don't thinkt he ADL even has X or wayland installed. > and before logging in, run turbostat over ssh > and observe PC8 percent residencies. Now increase > jiffies_till_first_fqs boot parameter value to 64 or so and try again. > You may be surprised how much PC8 percent increases by delaying RCU > and batching callbacks (via jiffies boot option) Admittedly this is > more amplified on ADL because of package-C-states, firmware and what > not, and isn’t as much a problem on Android; but still gives a nice > power improvement there. I can try; but as of now turbostat doesn't seem to work on that thing at all. I think localyesconfig might've stripped a required bit. I'll poke at it later.