Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp979360pxb; Fri, 15 Apr 2022 17:15:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLGbkj6IFaeSQTVVw5xRyW7KnjlrA1pA5ouwlL9Htsrxx3VsSfIro4KpvNr4YNtBEO9eKL X-Received: by 2002:a65:5b4b:0:b0:3a3:d8fb:6926 with SMTP id y11-20020a655b4b000000b003a3d8fb6926mr1035470pgr.76.1650068128874; Fri, 15 Apr 2022 17:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650068128; cv=none; d=google.com; s=arc-20160816; b=lMkBrLJZpfnab8HxzN/XNyEgG9n5aDCatYHxK1p7j35ndzHPhNb9uOCJV8A79hXHDQ 6RgWm3D5gncblEE71BRd37oQRgvAhJp9Fi1Xi9BEHZ2sXON+kc3c/E5htO5ekSfQb8d/ 2q6veQVtygtF5HWT6v3RRJwDoGFraasq/xnLCdTJcHewKJbSFqTf50442Dg2lFTMGWhs NIs7GAq+8YXuNf4hi7eSaNE27f8JcepOlKdjmOkwT5i/Q1pY3ZufondTZK4aKUSDcvZK +qP0KTg0+l+pnz9kZ1ghBkTcToacSbsRxJB3um0EXEAFnnAI3ezx2vXUmQ7UNTj2qiya nXRw== 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:dkim-signature; bh=Qq44QcgUTvrM0yR0uIBFO4qbEgfmXFTn9DFwrR1re2U=; b=xtG8i8g3uc7PtcavFOu56m8a/cb40XP3Y67azhAsn4uwhKtAEVtFKrG8EWLgSty/Gj Ev1OUbSVSLCzlLnVEgDTOZORlPkWiCwRi7LYaxoWWVxUkS7gYvQf2Eg2BFPYV1znO+FH /0vnDJc5ox6Ki8baImIPxxmU9Dpm6jMVPB2T5YyPuYaVM3WU/19aw5Dpqox1CSrN4PEn p1na0eXbaBe9ZUaKj+tLqXu3OywtNGqkS9BxtsqYmH7aaG2GltJn/GxhbNs1F2oteqXg Fai0U8QnsH6yMnf1eoX5IDNn56TM6QBi1ELL0NizFp0MAlc4OfzYLn+sP9dXCLvq3AUy W25A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=DJcQZgGg; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 188-20020a6309c5000000b0039956e51e13si2940586pgj.592.2022.04.15.17.15.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:15:28 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=DJcQZgGg; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 22CCD65152; Fri, 15 Apr 2022 17:15:21 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229476AbiDNQHP (ORCPT + 99 others); Thu, 14 Apr 2022 12:07:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349688AbiDNP5A (ORCPT ); Thu, 14 Apr 2022 11:57:00 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD1F5E65 for ; Thu, 14 Apr 2022 08:38:11 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id h15-20020a17090a054f00b001cb7cd2b11dso6004403pjf.5 for ; Thu, 14 Apr 2022 08:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Qq44QcgUTvrM0yR0uIBFO4qbEgfmXFTn9DFwrR1re2U=; b=DJcQZgGgCMSdEr73OHf4KjCFWkfmLDjCW6J+MKp7+BvlAxQbpy3LWtQHsiJRMomLKf QQy/cDZGSi7hIsxhUMiBI2sSOMqZ94VJvI/zsS2or5jz3Okd9ZEENLtR9gfrUpM0GVt1 wf5lYwEClRX+nU8oJkVa/PZ6nob4NgW5hiLs929efgHRtERBFzIt/30LvL5O1hf84NLO J1aRow7aurhrwwZWPNAfNAdaBqJISM1rd9EWMkjWuFN0GW8inMXzIqEAYbHBU4FruJQq 4rljZH0IKyhkSVXPeLRNiubyEjXunPkdPDp4YbCCgq/50ckpd/IrjcxSC19Vqx6P+aJH QzKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Qq44QcgUTvrM0yR0uIBFO4qbEgfmXFTn9DFwrR1re2U=; b=ow+aUYJxS0+E2LpYoCjWJ35qAKIONERYePNRqRNllFxTz8gVqOt+7cxUP2R/E4hBWJ lbr3yG+0pWcmlr4AUWwOCQpkCDSz59ETCgHj/kqCQQjWaLZXw+JuY7S00PidswxEiwGH MauftWpWBR99osUHLKDrN1oaoGQGS/2Ff9UhQ5pQ78ISjBmCyzZgCw5zGZtJuGByNm6i H1Ak43C+LMcw/nbT2bXyNuesgvT83oy/VUVKGUyiQNv7nc/gxzQXetYjSBF+LE1H7EGe O17uVdIngQxpgVKAbKpM70dGqFMe7MfgAV/ShClkoM9LHKfCd73Yffaf/NLKoAtlMdJA XGKA== X-Gm-Message-State: AOAM533JbzYzs4FBv+ogdYt1nEHda25BXYNxyS2hCNbo4RJiCO8p/hFU kZqawFV0hIeKdPShLXYGAYX4Tw== X-Received: by 2002:a17:903:2ca:b0:156:f1cc:7cb6 with SMTP id s10-20020a17090302ca00b00156f1cc7cb6mr41777445plk.174.1649950691276; Thu, 14 Apr 2022 08:38:11 -0700 (PDT) Received: from [10.255.214.21] ([139.177.225.227]) by smtp.gmail.com with ESMTPSA id d14-20020a65620e000000b003a1112c6cbesm1779587pgv.39.2022.04.14.08.38.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 08:38:10 -0700 (PDT) Message-ID: <60cbd089-f514-44eb-a629-62556936be35@bytedance.com> Date: Thu, 14 Apr 2022 23:38:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [RFC v2 2/2] sched/fair: introduce sched-idle balance Content-Language: en-US To: Josh Don Cc: Peter Zijlstra , Mel Gorman , Vincent Guittot , linux-kernel , Abel Wu References: <20220409135104.3733193-1-wuyun.abel@bytedance.com> <20220409135104.3733193-3-wuyun.abel@bytedance.com> <801da029-6bbe-2a0c-7de0-afffc3d5de02@bytedance.com> From: Abel Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 4/14/22 8:08 AM, Josh Don Wrote: >>>> /* >>>> * Use locality-friendly rq->overloaded to cache the status of the rq >>>> * to minimize the heavy cost on LLC shared data. >>>> @@ -7837,6 +7867,22 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env) >>>> if (kthread_is_per_cpu(p)) >>>> return 0; >>>> >>>> + if (unlikely(task_h_idle(p))) { >>>> + /* >>>> + * Disregard hierarchically idle tasks during sched-idle >>>> + * load balancing. >>>> + */ >>>> + if (env->idle == CPU_SCHED_IDLE) >>>> + return 0; >>>> + } else if (!static_branch_unlikely(&sched_asym_cpucapacity)) { >>>> + /* >>>> + * It's not gonna help if stacking non-idle tasks on one >>>> + * cpu while leaving some idle. >>>> + */ >>>> + if (cfs_rq_busy(env->src_rq) && !need_pull_cfs_task(env->dst_rq)) >>>> + return 0; >>> >>> These checks don't involve the task at all, so this kind of check >>> should be pushed into the more general load balance function. But, I'm >>> not totally clear on the motivation here. If we have cpu A with 1 >>> non-idle task and 100 idle tasks, and cpu B with 1 non-idle task, we >>> should definitely try to load balance some of the idle tasks from A to >>> B. idle tasks _do_ get time to run (although little), and this can add >>> up and cause antagonism to the non-idle task if there are a lot of >>> idle threads. >> >> CPU_SCHED_IDLE means triggered by sched_idle_balance() in which pulls >> a non-idle task for the unoccupied cpu from the overloaded ones, so >> idle tasks are not the target and should be skipped. >> >> The second part is: if we have cpu A with 1 non-idle task and 100 idle >> tasks, and B with >=1 non-idle task, we don't migrate the last non-idle >> task on A to B. > > It could be possible that we do want to migrate the last non-idle task > from A to B, if the weight sum of idle tasks on A is very high (easily > possible with affinity restrictions). So I think we should leave > regular load balance alone here if it really wants to move the > non-idle task, and wrap this entire block in an if (env->idle == > CPU_SCHED_IDLE). Makes sense. I will fix it in next version. Thanks & BR, Abel