Message ID | 202312141319+0800-wangjinchao@xfusion.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp8331518dys; Wed, 13 Dec 2023 21:21:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IH6L7W/ukUvKA7z2/yihHuPDpoU/P+k7dyhnsT88f3Po0J21/I20+YvKvQS4vcBwg+mBVoQ X-Received: by 2002:a05:6e02:b4f:b0:35d:57de:1e42 with SMTP id f15-20020a056e020b4f00b0035d57de1e42mr15230922ilu.6.1702531283748; Wed, 13 Dec 2023 21:21:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702531283; cv=none; d=google.com; s=arc-20160816; b=Heb2TRgyoOqUhpuURVJxVeLuF5DcDrEbkkcba+/Hr+gk935uX8S3lL1SuJ2jnfVLdx FSbRSr1G+PrnqCHImioeySh2zKJyUOBfrARRYH3n39tXa9Ka58z1KuChrrvEFypMNZgm MdaO4CjreTvQGnIDIKu0nDHBV1fQOlW31NRv1CT2ywR2fhWO5c4T1bGPbaWFSsVGmTGn WJp7hZI2ujd325GJ/hDqQ/ZWJKuqiwKBkVsyv3YicEOo6acOhEKgP5sjfdWsynbhPLm+ gEmvOyDuSI1lPfn4aU6jun9Ejg/w08dcMWaPVAsesf5jhlzJmPQ8JpCRZLih9OLyFJDz 7jpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date; bh=XQIqTgPL/Y1FcqaO9O6wge5VPxR58rI29FbKtjsCMjM=; fh=f40UFx4PIoN5VHjot5Te0Vsnl2epc2I3Vpkjl2f6MCo=; b=NiyaGIhYiz0RvBfLZ8XqrlBaCIDBV0sCyRwP1DCXqqkqBhsKgYMZPab5yYXb1gYjQ/ eSvM4DW1RAUhSPOhTQBJxLk+zot6w1NI+oPM547Z3NALf8FtpqTcy3+KpKS2WKXGkpaH yf9aP0y7p/tWJweULy5OZCtIjCvwIpZa3XsLMBfCZqLkP7XdOYWPDiZ/7yVQH2AdvpJd lRjm0GSNxIwixCqppb7lHcVGzmvWO7GVWMCJxwWqk2SIoBPZQDW47rfb0S8+PmRqckV9 lqDobFgkJK9+YLNRcP3czEMYepsdxI67liGDbwABywmVVqiN6GfuQiwSwXs2c9zst1sT wQ4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id h2-20020a170902f54200b001d08ac11b93si11014161plf.374.2023.12.13.21.21.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 21:21:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id E7957807798B; Wed, 13 Dec 2023 21:20:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443171AbjLNFUf (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Thu, 14 Dec 2023 00:20:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1443172AbjLNFUd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Dec 2023 00:20:33 -0500 Received: from wxsgout04.xfusion.com (wxsgout04.xfusion.com [36.139.87.180]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EA0E109 for <linux-kernel@vger.kernel.org>; Wed, 13 Dec 2023 21:20:35 -0800 (PST) Received: from wuxshcsitd00600.xfusion.com (unknown [10.32.133.213]) by wxsgout04.xfusion.com (SkyGuard) with ESMTPS id 4SrLF93WHFzB0S9n; Thu, 14 Dec 2023 13:17:01 +0800 (CST) Received: from localhost (10.82.147.3) by wuxshcsitd00600.xfusion.com (10.32.133.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 14 Dec 2023 13:20:30 +0800 Date: Thu, 14 Dec 2023 13:20:29 +0800 From: Wang Jinchao <wangjinchao@xfusion.com> To: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Daniel Bristot de Oliveira <bristot@redhat.com>, Valentin Schneider <vschneid@redhat.com>, <linux-kernel@vger.kernel.org> CC: <stone.xulei@xfusion.com>, <wangjinchao@xfusion.com> Subject: [PATCH] sched/fair: remove next_buddy_marked Message-ID: <202312141319+0800-wangjinchao@xfusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Originating-IP: [10.82.147.3] X-ClientProxiedBy: wuxshcsitd00600.xfusion.com (10.32.133.213) To wuxshcsitd00600.xfusion.com (10.32.133.213) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Dec 2023 21:20:45 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785233443617391722 X-GMAIL-MSGID: 1785233443617391722 |
Series |
sched/fair: remove next_buddy_marked
|
|
Commit Message
Wang Jinchao
Dec. 14, 2023, 5:20 a.m. UTC
Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair`
Signed-off-by: Wang Jinchao <wangjinchao@xfusion.com>
---
kernel/sched/fair.c | 2 --
1 file changed, 2 deletions(-)
Comments
On Thu, 14 Dec 2023 at 06:20, Wang Jinchao <wangjinchao@xfusion.com> wrote: > > Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair` > Fixes: 5e963f2bd465 ("sched/fair: Commit to EEVDF") > Signed-off-by: Wang Jinchao <wangjinchao@xfusion.com> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> > --- > kernel/sched/fair.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d7a3c63a2171..d2028bfa4e94 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8210,7 +8210,6 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int > struct task_struct *curr = rq->curr; > struct sched_entity *se = &curr->se, *pse = &p->se; > struct cfs_rq *cfs_rq = task_cfs_rq(curr); > - int next_buddy_marked = 0; > int cse_is_idle, pse_is_idle; > > if (unlikely(se == pse)) > @@ -8227,7 +8226,6 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int > > if (sched_feat(NEXT_BUDDY) && !(wake_flags & WF_FORK)) { > set_next_buddy(pse); > - next_buddy_marked = 1; > } > > /* > -- > 2.40.0 >
On 12/14/23 4:18 PM, Vincent Guittot Wrote: > On Thu, 14 Dec 2023 at 06:20, Wang Jinchao <wangjinchao@xfusion.com> wrote: >> >> Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair` >> > > Fixes: 5e963f2bd465 ("sched/fair: Commit to EEVDF") After this commit @pse preempts curr without being the NEXT_BUDDY, but IMHO it should be, so how about this? @@ -8259,8 +8259,11 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int /* * XXX pick_eevdf(cfs_rq) != se ? */ - if (pick_eevdf(cfs_rq) == pse) + if (pick_eevdf(cfs_rq) == pse) { + if (!next_buddy_marked) + set_next_buddy(pse); goto preempt; + } return; which will align with before.
On Thu, Dec 14, 2023 at 08:21:53PM +0800, Abel Wu wrote: > On 12/14/23 4:18 PM, Vincent Guittot Wrote: > > On Thu, 14 Dec 2023 at 06:20, Wang Jinchao <wangjinchao@xfusion.com> wrote: > > > > > > Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair` > > > > > > > Fixes: 5e963f2bd465 ("sched/fair: Commit to EEVDF") > > After this commit @pse preempts curr without being the NEXT_BUDDY, but > IMHO it should be, so how about this? > > @@ -8259,8 +8259,11 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int > /* > * XXX pick_eevdf(cfs_rq) != se ? > */ > - if (pick_eevdf(cfs_rq) == pse) > + if (pick_eevdf(cfs_rq) == pse) { > + if (!next_buddy_marked) > + set_next_buddy(pse); > goto preempt; > + } > > return; > > which will align with before. Seizing this opportunity to inquire about a question: What does "buddy" mean in the context of the scheduler? Is the effect the same between preempting after pick_evfd(cfs_rq) == pse and preempting after set_next_buddy(pse) followed by pick_evfd(cfs_rq) == pse? Would both scenarios result in pse becoming the next scheduled se?"
On 12/14/23 9:02 PM, Wang Jinchao Wrote: > On Thu, Dec 14, 2023 at 08:21:53PM +0800, Abel Wu wrote: >> On 12/14/23 4:18 PM, Vincent Guittot Wrote: >>> On Thu, 14 Dec 2023 at 06:20, Wang Jinchao <wangjinchao@xfusion.com> wrote: >>>> >>>> Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair` >>>> >>> >>> Fixes: 5e963f2bd465 ("sched/fair: Commit to EEVDF") >> >> After this commit @pse preempts curr without being the NEXT_BUDDY, but >> IMHO it should be, so how about this? >> >> @@ -8259,8 +8259,11 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int >> /* >> * XXX pick_eevdf(cfs_rq) != se ? >> */ >> - if (pick_eevdf(cfs_rq) == pse) >> + if (pick_eevdf(cfs_rq) == pse) { >> + if (!next_buddy_marked) >> + set_next_buddy(pse); >> goto preempt; >> + } >> >> return; >> >> which will align with before. > Seizing this opportunity to inquire about a question: > What does "buddy" mean in the context of the scheduler? struct sched_entity > > Is the effect the same between > preempting after pick_evfd(cfs_rq) == pse > and > preempting after set_next_buddy(pse) followed by pick_evfd(cfs_rq) == pse? > Would both scenarios result in pse becoming the next scheduled se?" Probably, since pse is the one preempts curr, pick_next_entity() could return pse directly without walking the rbtree. So the difference is in performance.
On Thu, 14 Dec 2023 at 13:23, Abel Wu <wuyun.abel@bytedance.com> wrote: > > On 12/14/23 4:18 PM, Vincent Guittot Wrote: > > On Thu, 14 Dec 2023 at 06:20, Wang Jinchao <wangjinchao@xfusion.com> wrote: > >> > >> Remove unused `next_buddy_marked` in `check_preempt_wakeup_fair` > >> > > > > Fixes: 5e963f2bd465 ("sched/fair: Commit to EEVDF") > > After this commit @pse preempts curr without being the NEXT_BUDDY, but > IMHO it should be, so how about this? > > @@ -8259,8 +8259,11 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int > /* > * XXX pick_eevdf(cfs_rq) != se ? > */ > - if (pick_eevdf(cfs_rq) == pse) > + if (pick_eevdf(cfs_rq) == pse) { > + if (!next_buddy_marked) > + set_next_buddy(pse); I don't think this is needed because : - NEXT_BUDDY is false by default so pick_next_entity() will not take care of this - pick_next_entity() will call pick_eevdf() which should return pse unless another se that want to run 1st, wakes up in the meantime and we should probably not take into account next buddy in this case > goto preempt; > + } > > return; > > which will align with before.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d7a3c63a2171..d2028bfa4e94 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8210,7 +8210,6 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int struct task_struct *curr = rq->curr; struct sched_entity *se = &curr->se, *pse = &p->se; struct cfs_rq *cfs_rq = task_cfs_rq(curr); - int next_buddy_marked = 0; int cse_is_idle, pse_is_idle; if (unlikely(se == pse)) @@ -8227,7 +8226,6 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int if (sched_feat(NEXT_BUDDY) && !(wake_flags & WF_FORK)) { set_next_buddy(pse); - next_buddy_marked = 1; } /*