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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A3A8C4332F for ; Sat, 17 Dec 2022 22:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230042AbiLQWKT (ORCPT ); Sat, 17 Dec 2022 17:10:19 -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-Google-Smtp-Source: AA0mqf5IpVljHD7IKf8/Ml2HfZdjjj82E7iP/3mUppjltS90NSenP+2rdzC5Eri16RwGheEvUmS+Kg== 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: 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