Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp111028imw; Thu, 14 Jul 2022 22:13:22 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s7bkHi8gP//0fhqUHtuIe7RjqtCHT2fJ+wdbzMxqYtgDwiHhDH6vZJQbaoquOkI7a2AYW9 X-Received: by 2002:a05:6a00:8cf:b0:522:93a6:46e9 with SMTP id s15-20020a056a0008cf00b0052293a646e9mr12401071pfu.62.1657862002692; Thu, 14 Jul 2022 22:13:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657862002; cv=none; d=google.com; s=arc-20160816; b=EBR/hS1ls7UYGdEYN0k3CGY8fm/OYBJtmaMER/0Go+qgFtjmmudyQBwas03X5YH2iH lwoemI4NAh3SGzOLizr68GmD3WEXwdLem7wOmqZ7C1vMukYo/OV+mOKPc2XxE2ciYZn0 INfF5ArdAujdyXBBmJpsZZMeBqzQRPoIDLBZmqWQt0F6HywBXz0Vl3ff1Dx6nem+5egl exOPolbpi60+RX399o81MP8Tq7+Y4rTikYheTIUvv1pEFV77+tIxiukLh1BDQb7GosUH SIBRQnAKgSi4YQiIjpjIaPc0NNBxg6/ByBT0OB/an2H6ouGAgqf0Xmb/m1SywKL35ogO BpxA== 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; bh=x3YB1aph0ikF19ivHdFNqAITPU6JGOZBiPWrVlHSbyM=; b=fdIED14pSx+i8PIZg+bU01cz/PqByVEGNaIiN61SaLPsfJmLv+XTfw+SfYQZZ5Pa74 5Bt7AUyLTUmG+Gb7rheI2xB6HsBENqpVaXh+NiRb/1gByjh6evgySPAS6u2HD3+KYrjH Xebqvasrfe9XyBXo02oqjdZTfs5leug7d6ivpxUJxTi31mOQNvMk3s3SDvFnZxeKMlSP J3ADzvDO/BIAr/ORoQi/BqtrPTFJK8iBmy0yOkzOTb4vja/r8NEYKzPYWe7+3BKSJa6r C0O7FtyNc0+olsTLvsl4NDPAfvV4gh8VPGe4/EVMPYpzVBacMnlnz7YIIpshVwLtFtaD NzhA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w11-20020a170902e88b00b0016a674598c2si4946190plg.527.2022.07.14.22.13.07; Thu, 14 Jul 2022 22:13:22 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229481AbiGOFIb (ORCPT + 99 others); Fri, 15 Jul 2022 01:08:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbiGOFI3 (ORCPT ); Fri, 15 Jul 2022 01:08:29 -0400 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EC2178DE9 for ; Thu, 14 Jul 2022 22:08:28 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046060;MF=cruzzhao@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0VJNsa4y_1657861703; Received: from 30.97.49.8(mailfrom:cruzzhao@linux.alibaba.com fp:SMTPD_---0VJNsa4y_1657861703) by smtp.aliyun-inc.com; Fri, 15 Jul 2022 13:08:24 +0800 Message-ID: <4107a52c-131e-d683-898d-cdd2c2448137@linux.alibaba.com> Date: Fri, 15 Jul 2022 13:08:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 1/3] sched/core: Fix the bug that task won't enqueue into core tree when update cookie Content-Language: en-US To: Peter Zijlstra Cc: mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org References: <1656403045-100840-1-git-send-email-CruzZhao@linux.alibaba.com> <1656403045-100840-2-git-send-email-CruzZhao@linux.alibaba.com> From: cruzzhao In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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 在 2022/7/4 下午4:53, Peter Zijlstra 写道: > Subject: sched/core: Fix the bug that task won't enqueue into core tree when update cookie > From: Cruz Zhao > Date: Tue, 28 Jun 2022 15:57:23 +0800 > > From: Cruz Zhao > > In function sched_core_update_cookie(), a task will enqueue into the > core tree only when it enqueued before, that is, if an uncookied task > is cookied, it will not enqueue into the core tree until it enqueue > again, which will result in unnecessary force idle. > > Here follows the scenario: > CPU x and CPU y are a pair of SMT siblings. > 1. Start task a running on CPU x without sleeping, and task b and > task c running on CPU y without sleeping. > 2. We create a cookie and share it to task a and task b, and then > we create another cookie and share it to task c. > 3. Simpling core_forceidle_sum of task a and b from /proc/PID/sched > > And we will find out that core_forceidle_sum of task a takes 30% > time of the sampling period, which shouldn't happen as task a and b > have the same cookie. > > Then we migrate task a to CPU x', migrate task b and c to CPU y', where > CPU x' and CPU y' are a pair of SMT siblings, and sampling again, we > will found out that core_forceidle_sum of task a and b are almost zero. > > To solve this problem, we enqueue the task into the core tree if it's > on rq. > > Fixes: 6e33cad0af49("sched: Trivial core scheduling cookie management") > Signed-off-by: Cruz Zhao > Signed-off-by: Peter Zijlstra (Intel) > Link: https://lkml.kernel.org/r/1656403045-100840-2-git-send-email-CruzZhao@linux.alibaba.com > --- > kernel/sched/core_sched.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > --- a/kernel/sched/core_sched.c > +++ b/kernel/sched/core_sched.c > @@ -56,7 +56,6 @@ static unsigned long sched_core_update_c > unsigned long old_cookie; > struct rq_flags rf; > struct rq *rq; > - bool enqueued; > > rq = task_rq_lock(p, &rf); > > @@ -68,14 +67,16 @@ static unsigned long sched_core_update_c > */ > SCHED_WARN_ON((p->core_cookie || cookie) && !sched_core_enabled(rq)); > > - enqueued = sched_core_enqueued(p); > - if (enqueued) > + if (sched_core_enqueued(p)) > sched_core_dequeue(rq, p, DEQUEUE_SAVE); > > old_cookie = p->core_cookie; > p->core_cookie = cookie; > > - if (enqueued) > + /* > + * Consider the cases: !prev_cookie and !cookie. > + */ > + if (cookie && task_on_rq_queued(p)) > sched_core_enqueue(rq, p); > > /* LGTM.