Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp4539209rwe; Tue, 30 Aug 2022 12:00:17 -0700 (PDT) X-Google-Smtp-Source: AA6agR7+hyEMX+W4+xUTOtn1ac3AAZVuIBrquWMqmaiBVjEoByYX/rwcFLNTEYSlDVnbQGCiF259 X-Received: by 2002:a17:907:7f9f:b0:73d:6e87:17ce with SMTP id qk31-20020a1709077f9f00b0073d6e8717cemr17685852ejc.366.1661886017082; Tue, 30 Aug 2022 12:00:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661886017; cv=none; d=google.com; s=arc-20160816; b=gUM4vv8u45meBQa5YaAZAacUuYd1r19+UqG6rsJ9JggMBUt98DFc3dhjpAipCf7s7X mGTVFQ7e21I1i1/A7JFJl1y10UQqH3YBVe/dxw6exRiYfIXYSpq6bqJMmxALBv8RgrFz 8S7QIN+y8HLPqx/XFC+d4M59V/jqKckrKUDw+WLol3hoahr8k8mjrMkJTeF2+aA1beIN QiJeu6A3fPJZt5EP08Kzwuek4SvoDIe0dSFRAUeE0GJHmVAwjit5lgDO+PMb5PtFm7VO /QmXUMf6GzLyqgW2eUSELovLNhYgCJfwM4ahM1P/OdzRyK1Z5pNLCCeN4f7ro3USaKjF +CWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=XaXlF349lOKckpeRFZDQNo5GwNs0MMYghB0K5tskEEA=; b=0JfbV+a8l26CFfyQT599vuKOiqSaWU3kaHX7awnMD7qif00Dj7XDok71ZMlEIOxa0E j3ts2QVnlAzamcwdS3A/Ydyx119GIdM9TGOZ4A0J/pPmRBc9qEmwRlzU2bEF5vr5RapE hQGpfM4716a1MmXIKK8lmhBEgRJhtlI97Zqm08kxY3p5rT6540bj0ZXWfv83Xp5YDqzv 02/chUefND9WiGzLHsY8gPg+6oaj5dEnVNKIRpjXLUVEz7Tcwirf7tdFGSpiJpdd1y3t IIq5NokxDRRBi5oDHwMlyIlQbgktEB04vosatgmriqww1YV8nZnMv5zZOhSN6Yi5TlN/ E3sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=v2Em28vJ; 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 jr22-20020a170906a99600b00710487d3a4fsi8207683ejb.67.2022.08.30.11.59.51; Tue, 30 Aug 2022 12:00:17 -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=@joelfernandes.org header.s=google header.b=v2Em28vJ; 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 S231594AbiH3SrH (ORCPT + 99 others); Tue, 30 Aug 2022 14:47:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229735AbiH3SrE (ORCPT ); Tue, 30 Aug 2022 14:47:04 -0400 Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7430B67C93 for ; Tue, 30 Aug 2022 11:47:02 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id l5so9385621qvs.13 for ; Tue, 30 Aug 2022 11:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=XaXlF349lOKckpeRFZDQNo5GwNs0MMYghB0K5tskEEA=; b=v2Em28vJsFBxBufUF/UfGuZsx0qmO1twBw6Du9kdtlLTlSUTLRWLJKsvNJuHfTNxNt 0UOo8jfgTrVj7vUnWZYdWCHIqLtLRaryAknxGqPmsUtfipNUWVah4oHCUMWxbP8qMvP3 YcEWVHQsCqmn6Jbi8oT3NZkdRTDcEMh0U2EbA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=XaXlF349lOKckpeRFZDQNo5GwNs0MMYghB0K5tskEEA=; b=rWWY6JFHAPRBCoqptA4t7K3Sdqwjr54UM6laNvltz3ll6DgioO5K96DeGzK2xB4R2O hoZaMrhHT3R5ZWcVtynrQKBWaQsUU9U8F1V7YN5IrxssOrUirkPnI1mt1qsSbMF7pz1d tpzlSiNQjn1lX7xFl09zf8IczQZsTbsEo9wRvUcI1CCS69fz93UmzOECRo2XJOweI66Q ItpvkWqWVNfgf4mAvp0bR917khCRv9ve2Wxbp2s6+Eewio2WVni18V+43Fiy+e1Ow9fz yQFaSqe0LFHub/vrWdka4eN2x+483IQ4JUL9S27aYIUDmHB7s2FEfhVj7ymboSXQ022t QJaw== X-Gm-Message-State: ACgBeo11O2HDh1aEGtL3q5v7t+Xkv8mCpLra36TocxEPVpphZbZyei71 L3pCbXWlQuR1XY34iJOjtfrIBA== X-Received: by 2002:a05:6214:ccf:b0:499:72d:ccf9 with SMTP id 15-20020a0562140ccf00b00499072dccf9mr7640496qvx.116.1661885221571; Tue, 30 Aug 2022 11:47:01 -0700 (PDT) Received: from [10.0.0.40] (c-73-148-104-166.hsd1.va.comcast.net. [73.148.104.166]) by smtp.gmail.com with ESMTPSA id l5-20020a37f905000000b006af3f3b385csm8448512qkj.98.2022.08.30.11.47.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Aug 2022 11:47:01 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2022 14:46:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous fixes Content-Language: en-US To: Frederic Weisbecker , "Paul E. McKenney" Cc: Dietmar Eggemann , LKML , Rushikesh S Kadam , "Uladzislau Rezki (Sony)" , Neeraj upadhyay , Steven Rostedt , rcu , Vineeth Pillai References: <20220819204857.3066329-1-joel@joelfernandes.org> <20220829134045.GA54589@lothringen> <1f7dd31b-f4d0-5c1c-ce28-c27f75c17f05@joelfernandes.org> <20220829194622.GA58291@lothringen> <20220829204202.GQ6159@paulmck-ThinkPad-P17-Gen-1> <20220830105324.GA71266@lothringen> <20220830114343.GS6159@paulmck-ThinkPad-P17-Gen-1> <20220830160316.GC71266@lothringen> <20220830162244.GA73392@lothringen> From: Joel Fernandes In-Reply-To: <20220830162244.GA73392@lothringen> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no 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 8/30/2022 12:22 PM, Frederic Weisbecker wrote: > On Tue, Aug 30, 2022 at 06:03:16PM +0200, Frederic Weisbecker wrote: >> On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote: >>> On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote: >>>> On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote: >>>>> On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote: >>>>>> On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker wrote: >>>>>>> On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote: >>>>>>>> On 8/29/2022 9:40 AM, Frederic Weisbecker wrote: >>>>> >>>>> [ . . . ] >>>>> >>>>>>>>> 2) NOCB implies performance issues. >>>>>>>> >>>>>>>> Which kinds of? There is slightly worse boot times, but I'm guessing that's do >>>>>>>> with the extra scheduling overhead of the extra threads which is usually not a >>>>>>>> problem except that RCU is used in the critical path of boot up (on ChromeOS). >>>>>>> >>>>>>> I never measured it myself but executing callbacks on another CPUs, with >>>>>>> context switches and locking can only involve significant performance issues if callbacks >>>>>>> are frequent. So it's a tradeoff between power and performance. >>>>>> >>>>>> In my testing of benchmarks on real systems with 8-16 CPUs, the >>>>>> performance hit is down in the noise. It is possible though that maybe >>>>>> one can write a non-realistic synthetic test to force the performance >>>>>> issues, but I've not seen it in the real world. Maybe on >>>>>> networking-heavy servers with lots of cores, you'll see it but their >>>>>> batteries if any would be pretty big :-). >>>>> >>>>> To Frederic's point, if you have enough servers, even a 1% decrease in >>>>> power consumption is a very big deal. ;-) >>>> >>>> The world has enough servers, for that matters ;-) >>> >>> True enough! Now you need only demonstrate that call_rcu_lazy() for >>> !rcu_nocbs servers would actually deliver that 1%. ;-) >> >> Well, !rcu_nocbs is not only used by server but also by pretty much >> everything else, except android IIUC. I can't really measure the whole >> world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc >> device differs from the idleness of an android device. >> >> But ok I'll try to measure that. > > Although who knows, may be some periodic file operation while idle are specific > to Android. I'll try to trace lazy callbacks while idle and the number of grace > periods associated. One potential usecase could be logging if the logger is opening and closing log files during logging updates. Uladzislau reported this on Android, that a system logger was doing file open/close and triggering RCU that way (file table, dentry, inode code all queue RCU callbacks). Thanks, - Joel