Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp647520rwj; Sat, 17 Dec 2022 14:54:12 -0800 (PST) X-Google-Smtp-Source: AA0mqf5rB/ZkJrnI2+Ukxgqwqo6Qr5lAw99mHSvfr/owbw2btLHA1u5Qh4cd0TtXp1KzLQD6P3PE X-Received: by 2002:a17:906:1441:b0:7bf:c00d:5072 with SMTP id q1-20020a170906144100b007bfc00d5072mr32056778ejc.72.1671317652111; Sat, 17 Dec 2022 14:54:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671317652; cv=none; d=google.com; s=arc-20160816; b=ySMmvVhci9tXeox9pmlVeCbG1WXMY3upncrQzFelbKJWuYfrrj6wy2oIdvgaz9yJI+ RYjy9R3zwgQnJKUnsbJgFYHsh5tuva+RvFIKSTCkTl/iu9Evsp8m01YhNmIBppPxNhGA 5FKvoJyZ1Jmu3pOjn/I309uzvqRA6T1xvhYagMxd0gtDbeAwHtGSf2AjatQ0bxkxlzaU dRxdE2mvr2kk3BbZw4ZdF2JQTAWco1KKt0xashyISKOwD3V8guQDOEZVOE+F1BdeaAPb f6J1+qgk3cQITyIRCG00pEcGZkaG/5xKGLoh53Acl/mSgKoX8HhrgVNohYHICuqYfHWh KKEw== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KgznWvPnejDwQ5G194p3C76c3g3BZCk+ljWB2J8CwsQ=; b=mURgbYncFwd6/0I+UoC8o8dsM+bkyKhrVI4C0ifMNRQQU/z0Kwr8JaZPfNgWGZ755D YbLrrLqDWX/U5nvFgaqawmZJmBhaZ+PJPghKpHAPqLFMNlRfNPpNVH7bNMn7S9MRVI9d fr/JCH4dhcv9afuv+1xuP4mkytnbXOAvSH8NJYl3ijb1gL2dUA4TOXpfPP3JPkv7QvtI aaG56rFZiCN6frxL0WFqxMBwUTmQMtkjvZCb9QS/t1APcr4UPVF5n1Q1IaA13g0XKUxK 6B8SlEV3Tvxl16gO4oKDS+0Gdkw5hNFZGmY4QA5KU71WMld5vhfYw2Owi3lIhWa4S/UB pmAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@layalina-io.20210112.gappssmtp.com header.s=20210112 header.b=z60Sqh8H; 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 cs18-20020a170906dc9200b007c172bd367fsi3080289ejc.193.2022.12.17.14.53.51; Sat, 17 Dec 2022 14:54:12 -0800 (PST) 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=@layalina-io.20210112.gappssmtp.com header.s=20210112 header.b=z60Sqh8H; 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 S229885AbiLQWKS (ORCPT + 70 others); Sat, 17 Dec 2022 17:10:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229695AbiLQWKP (ORCPT ); Sat, 17 Dec 2022 17:10:15 -0500 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69262F5BC for ; Sat, 17 Dec 2022 14:10:14 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id h7so5564175wrs.6 for ; Sat, 17 Dec 2022 14:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KgznWvPnejDwQ5G194p3C76c3g3BZCk+ljWB2J8CwsQ=; b=z60Sqh8HjXVzJehaGoNvHfThICmNQU5lyWECyXUwoLZzKHyW9IHSXNmSWfyibVk0qW sLCWrbAdZFv6iyQBOPoWofv3FHef9K4l2JVI3ilXVkmp5ccAWbk07qMJTtcBt33VvGt6 w61fp0MZNGXsFgXU9m9Uw+w0IsRqbnGCDFzMh5PEiav/r5b/Y5eJxOBH2qVNIOIP9RXv /WOsw+fuuy0EViw1TBP9jTZXo8bFfl2dWhIoXkQlCE2V9ULtRLS1vqMxUpV+/WuBNhVY vkwYXE8cUzsNbKOqkn+wgFEixC0PPzcsIl2XmdOoES8b7dJ3OUn14AomYEJA4XwRi2bC zNRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KgznWvPnejDwQ5G194p3C76c3g3BZCk+ljWB2J8CwsQ=; b=dtI2WHsXfiHxe+yZdDVwfasNimPJT5GJWS1GAEEVrEaN2nFvctFp7nx5m4EasxW3pg YL30kfqvBQQKZ0cge9EGnetD1pqsfIHf15HBGYA4Ois7EOLhKHc3c/GjYr0q6U46omDC cHoFoOT1bwXkixnzT3eTnZSxpnlq9FmEdl64qQYBSzTPZPTqRMqD6mdszscQNLSCwgIG DJY1rfudny5MUOfir377KZbOezRlMfjVt0WCePhWMv9nLr/X3AtH6OKsD8ywSobZXLAv JdSaY4QRQGaufZqK0e/DBgp1z8KXUkwxnO5AI+N239REBmq2yBf+twO7Wae8ogmQ1t4L ZGvQ== X-Gm-Message-State: ANoB5pkS0HxdW40Fnd/wbKO0cwXfkVVyedYsefZND2xtE4w7fjIcRyGV rGU/WbCymfe4cj6hvBzCrGK3Ig== X-Received: by 2002:a5d:4a0b:0:b0:242:10aa:202f with SMTP id m11-20020a5d4a0b000000b0024210aa202fmr21415703wrq.57.1671315012800; Sat, 17 Dec 2022 14:10:12 -0800 (PST) Received: from airbuntu (host86-130-134-87.range86-130.btcentralplus.com. [86.130.134.87]) by smtp.gmail.com with ESMTPSA id i5-20020a5d5585000000b0024207478de3sm5728624wrv.93.2022.12.17.14.10.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Dec 2022 14:10:12 -0800 (PST) Date: Sat, 17 Dec 2022 22:10:11 +0000 From: Qais Yousef To: Waiman Long Cc: Juri Lelli , peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, tj@kernel.org, linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, lizefan@huawei.com, dietmar.eggemann@arm.com, cgroups@vger.kernel.org, Vincent Guittot , Wei Wang , Rick Yiu , Quentin Perret Subject: Re: [PATCH v9 3/8] cpuset: Rebuild root domain deadline accounting information Message-ID: <20221217221011.pqunktdfgkaoufrd@airbuntu> References: <20190719140000.31694-1-juri.lelli@redhat.com> <20190719140000.31694-4-juri.lelli@redhat.com> <20221216233501.gh6m75e7s66dmjgo@airbuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 12/16/22 21:26, Waiman Long wrote: > On 12/16/22 18:35, Qais Yousef wrote: > > Hi > > > > On 07/19/19 15:59, Juri Lelli wrote: > > > When the topology of root domains is modified by CPUset or CPUhotplug > > > operations information about the current deadline bandwidth held in the > > > root domain is lost. > > > > > > This patch addresses the issue by recalculating the lost deadline > > > bandwidth information by circling through the deadline tasks held in > > > CPUsets and adding their current load to the root domain they are > > > associated with. > > > > > > Signed-off-by: Mathieu Poirier > > > Signed-off-by: Juri Lelli > > > --- > > We see that rebuild_root_domain() can take 10+ ms (I get a max of 20ms quite > > consistently) on suspend/resume. > > > > Do we actually need to rebuild_root_domain() if we're going through > > a suspend/resume cycle? > > > > ie: would something like the below make sense? We'd skip this logic if > > cpuhp_tasks_frozen is set which indicates it's not a real hotplug operation but > > we're suspending/resuming. > > > > > > Cheers > > > > -- > > Qais Yousef > > > > > > --->8--- > > > > > > From 4cfd50960ad872c5eb810ad3038eaf840bab5182 Mon Sep 17 00:00:00 2001 > > From: Qais Yousef > > Date: Tue, 29 Nov 2022 19:01:52 +0000 > > Subject: [PATCH] sched: cpuset: Don't rebuild sched domains on suspend-resume > > > > Commit f9a25f776d78 ("cpusets: Rebuild root domain deadline accounting information") > > enabled rebuilding sched domain on cpuset and hotplug operations to > > correct deadline accounting. > > > > Rebuilding sched domain is a slow operation and we see 10+ ms delays > > on suspend-resume because of that. > > > > Since nothing is expected to change on suspend-resume operation; skip > > rebuilding the sched domains to regain some of the time lost. > > > > Debugged-by: Rick Yiu > > Signed-off-by: Qais Yousef (Google) > > --- > > kernel/cgroup/cpuset.c | 6 ++++++ > > kernel/sched/deadline.c | 3 +++ > > 2 files changed, 9 insertions(+) > > > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > > index b474289c15b8..2ff68d625b7b 100644 > > --- a/kernel/cgroup/cpuset.c > > +++ b/kernel/cgroup/cpuset.c > > @@ -1067,6 +1067,9 @@ static void update_tasks_root_domain(struct cpuset *cs) > > struct css_task_iter it; > > struct task_struct *task; > > + if (cpuhp_tasks_frozen) > > + return; > > + > > css_task_iter_start(&cs->css, 0, &it); > > while ((task = css_task_iter_next(&it))) > > @@ -1084,6 +1087,9 @@ static void rebuild_root_domains(void) > > lockdep_assert_cpus_held(); > > lockdep_assert_held(&sched_domains_mutex); > > + if (cpuhp_tasks_frozen) > > + return; > > + > > rcu_read_lock(); > > /* > > rebuild_root_domains() is the only caller of update_tasks_root_domain(). So > the first hunk is redundant as update_tasks_root_domain() won't be called > when cpuhp_tasks_frozen is set. True. I went overzealous and protected all the functions. Thanks! -- Qais Yousef