Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2945993ybk; Tue, 12 May 2020 12:01:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwwcuivDxevvDwsm0MCV1Ctkfw1gA2mPAdtvs+k+SOFcQoULQRAR8ZCeOfBqU8QOkPmxiU X-Received: by 2002:a17:906:eb83:: with SMTP id mh3mr8254191ejb.361.1589310070740; Tue, 12 May 2020 12:01:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589310070; cv=none; d=google.com; s=arc-20160816; b=b3AU2P4Aox63ON2lVkUhR+cXUYuqQo3tkozOhuXEo5gVRXQMFgYn/6p6q9BRrnV+m3 4+z5oaDTAr7aFhZ2CrQpQaueCq6bLZd2/E3p6eacZZMJecVi2NK6kaDVTXg4pCN6hF/2 vQRd9gUF8cUieE+kT0OHFxqX33rv8IO96YHXqNSrDAxCCJ7/+rlEkqRFRjgXWHTAOjug xx7xKkVRCmab8DlwByuS4nSyEZnrQtQOl1Mk0Rat041sVfdUrrueU6RBQmNUb/u4W25l FNIUCb1E0GriiqXVJA806cRqT135tTTaGfVMNUoCrIIfZSu9pzDh1YQySOet3kOK2GFv D9Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:dkim-signature; bh=r/7av/wBuBjyXx7XMiK2qASAvEvs+Io5wqGx7zancQ4=; b=s1PFxL84ScJsthuu8IYWh4dTimmhZP7AUscLkMY/pE0EcQNWuJzfIO0ZxknZAPwRLc VplavLqLY5Dn/D+50uPmDB/FwdoG8GjfCShL9c/eTL51jyyVyws0Vey5DSeius+R7/Np HRS+yhELhAGmCpfHyixWfx5f7e+m+YvMi5AB9OhfulNwnpDMC6Wxc/LzkyIHIOMeqBwd tstAzPILKQqVGu148TTCYHj+MSgNvPwMf9m+5UALewXbdhlJNs2dr7UrnUzVrsQJKLr0 96okxyBt1ZM6ZfatjjVDkxMQ2pzOn4UYV2iQCJ1Uk0qLWYuW0Dm3CR5yjwI49YnKl+4F eEYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=V1++C4FV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w21si8356362edt.595.2020.05.12.12.00.42; Tue, 12 May 2020 12:01:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=V1++C4FV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730711AbgELS7K (ORCPT + 99 others); Tue, 12 May 2020 14:59:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725938AbgELS7J (ORCPT ); Tue, 12 May 2020 14:59:09 -0400 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD4CAC061A0C for ; Tue, 12 May 2020 11:59:08 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id 145so6784130pfw.13 for ; Tue, 12 May 2020 11:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=r/7av/wBuBjyXx7XMiK2qASAvEvs+Io5wqGx7zancQ4=; b=V1++C4FVyDcfv1SYZmzbp9TLiQyj1wT0X9ityBNfvWRnkqClPrBhdh9ctbk4zgBPwJ uoi0I7y5hL6a3Q6z7f7KZT/6hcUdkqIQXFVT0P1xXa+89++fBBi+N0kpj8OJNTaXrsto xzxvs3wsCgFlVwvMs6Y0AAii1nsDaPw6hykj2X0h2OaGLNImRu77EaniqWQVSW3QWYiq qHooGpL0lmuYrMvamY1yWlkveRmiUOGJSezD+j6kYYQ/5O8FyTItttA4ViCNtyBVoIuX Fmi3OQPHkoOkjBSMPUWvOsbDeRS4cMW3l0g02KbOJMgEDw8wDCkmXpycIzEkKWPMJqDe FsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=r/7av/wBuBjyXx7XMiK2qASAvEvs+Io5wqGx7zancQ4=; b=cdgQhr1dlLPRuqSsl4adL1oto3f5De9VKAYrJO995nEdTvzLq3NeqPjJxsDN01M+TW zVGPOnJjjbeOhXQvP95wpbtVD7qzTMCbkXBzlitZyN0eO9jieOsA2uAYG+AFJEHCc3RE yl7DkGiMH6cz6aRO9tboo4VMEvdHI7lT2omFySjMYablH9HARs/udtXidLBv8JHPXKlW utRMtwXwz3j2tNslAFvacX9F+eRhh+cohHYE8tK5qs+4I4THLdlBPUiyM5Dvd9JsTxfZ 40Zkry1mSaCb3odZ2sfUKKbYuxNOO2/1NQmVdnYNrs+ebh0m/tJqZijyXxrUv8lqG2q1 L3GA== X-Gm-Message-State: AGi0PubPbNQMl+nU7ds8L+Sg3COU2wCcF0FZ8IIpLeHtNZxazyakYzEL khRlmTJgknpIugKvfUqHMmjvpA== X-Received: by 2002:a62:e30f:: with SMTP id g15mr22497515pfh.150.1589309947986; Tue, 12 May 2020 11:59:07 -0700 (PDT) Received: from bsegall-glaptop.localhost (c-73-71-82-80.hsd1.ca.comcast.net. [73.71.82.80]) by smtp.gmail.com with ESMTPSA id q1sm3080218pfg.194.2020.05.12.11.59.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 11:59:06 -0700 (PDT) From: bsegall@google.com To: Vincent Guittot Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org, pauld@redhat.com, ouwen210@hotmail.com Subject: Re: [PATCH] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list References: <20200511191320.31854-1-vincent.guittot@linaro.org> Date: Tue, 12 May 2020 11:59:04 -0700 In-Reply-To: <20200511191320.31854-1-vincent.guittot@linaro.org> (Vincent Guittot's message of "Mon, 11 May 2020 21:13:20 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vincent Guittot writes: > Although not exactly identical, unthrottle_cfs_rq() and enqueue_task_fair() > are quite close and follow the same sequence for enqueuing an entity in the > cfs hierarchy. Modify unthrottle_cfs_rq() to use the same pattern as > enqueue_task_fair(). This fixes a problem already faced with the latter and > add an optimization in the last for_each_sched_entity loop. > > Fixes: fe61468b2cb (sched/fair: Fix enqueue_task_fair warning) > Reported-by Tao Zhou > Signed-off-by: Vincent Guittot > --- > > This path applies on top of 20200507203612.GF19331@lorien.usersys.redhat.com > and fixes similar problem for unthrottle_cfs_rq() > > kernel/sched/fair.c | 37 ++++++++++++++++++++++++++++--------- > 1 file changed, 28 insertions(+), 9 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e2450c2e0747..4b73518aa25c 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4803,26 +4803,44 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq) > idle_task_delta = cfs_rq->idle_h_nr_running; > for_each_sched_entity(se) { > if (se->on_rq) > - enqueue = 0; > + break; > + cfs_rq = cfs_rq_of(se); > + enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP); > > + cfs_rq->h_nr_running += task_delta; > + cfs_rq->idle_h_nr_running += idle_task_delta; > + > + /* end evaluation on encountering a throttled cfs_rq */ > + if (cfs_rq_throttled(cfs_rq)) > + goto unthrottle_throttle; > + } > + > + for_each_sched_entity(se) { > cfs_rq = cfs_rq_of(se); > - if (enqueue) { > - enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP); > - } else { > - update_load_avg(cfs_rq, se, 0); > - se_update_runnable(se); > - } > + > + update_load_avg(cfs_rq, se, UPDATE_TG); > + se_update_runnable(se); > > cfs_rq->h_nr_running += task_delta; > cfs_rq->idle_h_nr_running += idle_task_delta; > > + > + /* end evaluation on encountering a throttled cfs_rq */ > if (cfs_rq_throttled(cfs_rq)) > - break; > + goto unthrottle_throttle; > + > + /* > + * One parent has been throttled and cfs_rq removed from the > + * list. Add it back to not break the leaf list. > + */ > + if (throttled_hierarchy(cfs_rq)) > + list_add_leaf_cfs_rq(cfs_rq); > } > > if (!se) The if is no longer necessary, unlike in enqueue, where the skip goto goes to this if statement rather than past (but enqueue could be changed to match this). Also in general if we are making these loops absolutely identical we should probably pull them out to a common function (ideally including the goto target and following loop as well). > add_nr_running(rq, task_delta); > > +unthrottle_throttle: > /* > * The cfs_rq_throttled() breaks in the above iteration can result in > * incomplete leaf list maintenance, resulting in triggering the > @@ -4831,7 +4849,8 @@ void unthrottle_cfs_rq(struct cfs_rq *cfs_rq) > for_each_sched_entity(se) { > cfs_rq = cfs_rq_of(se); > > - list_add_leaf_cfs_rq(cfs_rq); > + if (list_add_leaf_cfs_rq(cfs_rq)) > + break; Do we also need to handle the case of tg_unthrottle_up followed by early exit from unthrottle_cfs_rq? I do not have enough of an idea what list_add_leaf_cfs_rq is doing to say. > } > > assert_list_leaf_cfs_rq(rq);