Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4007051pxb; Tue, 25 Jan 2022 01:12:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwWB+BDveMw679B+sbupuHPDtk74sdNWNS2PqY5CLaeTDKEAZHBHKH3OjAL75T3aeR8BOya X-Received: by 2002:a17:902:6bcc:b0:14a:bd99:1ae9 with SMTP id m12-20020a1709026bcc00b0014abd991ae9mr17867990plt.62.1643101943593; Tue, 25 Jan 2022 01:12:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643101943; cv=none; d=google.com; s=arc-20160816; b=YG8IuQ21qgds4acS7x1Uy4QdrET9M9h6b3QRt0Minu9nw9Thk7++vPcoIFxcs0qN7j /tFASt56UW6gElzy73tNOj4CvBhhqUKQucjzPP3ntxd9ElvTWYQx8be9ruutbU435JO3 dA9swBMtDBFL6t7xi2IbT0fZlDCrtmy9VyAknimEwD7wMggVEM+z+Ry5TAMhxtC3SDhX Mw2AyEIfjNMDdlfnJtN8qTP6Yp+YSZkX9PizpI+aEhIn9lsuO+naia8zflDPDTcUKjmI FmCzaQnxOJC6t2c+9BOJID7ClYX1Dw3NG4oxEbMbS58QAfaRHP8R6hgWpJqFHvTbeYwA P0SQ== 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=Zr+uci7nAntwhy8NrWrL5PmRMbYwGWsGjAlVl3fZ4k0=; b=Zbax8VihxFU879P+pEQ54p9TuSoeL8QNUmNxo48irhelMvwnFcKCXNEzHM2Ipk76mm L8RHHmCe6jJGghfTP9PDSe34cEMx0k9Ks2heKnmJPMWnZMOtRKfRpFlQBHhNKmKOzmbE Kfj+aFVAA66xIKcE4UB2DWfbmq3WRkgDVSK3pW5Av9fSk95fu9BJOPXwSMgyAdyPbixR tTdA+AMCE+/UFh/mDPg1+DUWS86NoM3gnWL3LB5p5w6XOj1VTvCcAJ33LY0P64vxYofz 7whEDMQZbYScc19S2WjRSvds84yP0o0hNmQ6Ru/WklV6rWQnnG+bInsnDSeUj6r17Fkj tbZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=cCIsVpRp; 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=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g15si16465252pfv.111.2022.01.25.01.12.11; Tue, 25 Jan 2022 01:12:23 -0800 (PST) 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=@quicinc.com header.s=qcdkim header.b=cCIsVpRp; 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=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442902AbiAYHL7 (ORCPT + 99 others); Tue, 25 Jan 2022 02:11:59 -0500 Received: from alexa-out-sd-02.qualcomm.com ([199.106.114.39]:6123 "EHLO alexa-out-sd-02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1442276AbiAYHJC (ORCPT ); Tue, 25 Jan 2022 02:09:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1643094542; x=1674630542; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Zr+uci7nAntwhy8NrWrL5PmRMbYwGWsGjAlVl3fZ4k0=; b=cCIsVpRp+Hp7ZnvPMKZvI6zOPlq8SyeACy5LWty6UNFH93bQpbPDggrl 5DGYmXa4XhTouQUN7VhetFlQNz0acGXWtmrdOyJ1aY93lxVtJQGtpkUic Qexs7fAzCS/cB6AiU/lmKd0iXe6MyxgT2sQpmjwd7DuSdoYYue9rj8L79 M=; Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by alexa-out-sd-02.qualcomm.com with ESMTP; 24 Jan 2022 23:08:59 -0800 X-QCInternal: smtphost Received: from unknown (HELO nasanex01a.na.qualcomm.com) ([10.52.223.231]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2022 23:08:59 -0800 Received: from [10.216.52.178] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Mon, 24 Jan 2022 23:08:54 -0800 Message-ID: Date: Tue, 25 Jan 2022 12:38:51 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v2] sched/fair: Prefer small idle cores for forkees Content-Language: en-US To: Vincent Guittot CC: , , , , , , , , , , References: <20220121050233.8708-1-quic_ctheegal@quicinc.com> From: Chitti Babu Theegala In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01a.na.qualcomm.com (10.52.223.231) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/21/2022 7:57 PM, Vincent Guittot wrote: > On Fri, 21 Jan 2022 at 06:03, Chitti Babu Theegala > wrote: >> >> Newly forked threads don't have any useful utilization data yet and >> it's not possible to forecast their impact on energy consumption. > > It would be worth mentioning that you consider only EAS mode in the patch > >> These forkees (though very small, most times) end up waking big > > The assumption that " (though very small, most times)" is maybe true > for the cases that you are interested in and you monitor, but it's not > always true. It seems that Vincent D. raised some concerns about > forkee which would not be small at the end Agreed. >> cores from deep sleep for that very small durations. >> >> Bias all forkees to small cores to prevent waking big cores from deep > > you are testing idlest_sgs->idle_cpus so you don't bias to small cores > but small & idle cores but if there is no small idle core then you > will wake up a big core though the forkees are small most times > The function "find_idlest_cpu" expected to return idle cpu. So, I followed the same. If idle small cpu is available, then we can use it otherwise its ok to wakeup big cpu for newly forked tasks. I felt that using idle CPUs for new tasks will be better as that would give them a faster chance to run immediately. >> sleep to save power. > > Then why do you want to wake up a small core from deep state instead > of packing in one of these already running cpus? If you care about > power, selecting a small idle core may not always be the best choice. > Would it be better to select a non idle cpu with largest spare > capacity at the current opp ? > How about running find_energy_efficient_cpu() for newly forked tasks as well (with some default util value configured) ? >> >> Signed-off-by: Chitti Babu Theegala >> --- >> Changes in v2: >> 1. Enclosed the EAS check for this small core preferring logic >> --- >> kernel/sched/fair.c | 18 +++++++++++++----- >> 1 file changed, 13 insertions(+), 5 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index c6046446c50b3..72f9ea7c98c05 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -5872,7 +5872,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, >> } >> >> static struct sched_group * >> -find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu); >> +find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu, int sd_flag); >> >> /* >> * find_idlest_group_cpu - find the idlest CPU among the CPUs in the group. >> @@ -5959,7 +5959,7 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p >> continue; >> } >> >> - group = find_idlest_group(sd, p, cpu); >> + group = find_idlest_group(sd, p, cpu, sd_flag); >> if (!group) { >> sd = sd->child; >> continue; >> @@ -8885,7 +8885,8 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, >> static bool update_pick_idlest(struct sched_group *idlest, >> struct sg_lb_stats *idlest_sgs, >> struct sched_group *group, >> - struct sg_lb_stats *sgs) >> + struct sg_lb_stats *sgs, >> + int sd_flag) >> { >> if (sgs->group_type < idlest_sgs->group_type) >> return true; >> @@ -8922,6 +8923,13 @@ static bool update_pick_idlest(struct sched_group *idlest, >> if (idlest_sgs->idle_cpus > sgs->idle_cpus) >> return false; >> >> + if (sched_energy_enabled()) { > > This is not enough, the find_energy_efficient_cpu() returns early to > fallback to the default performance mode when the system is > overutilized > > >> + /* Select smaller cpu group for newly woken up forkees */ >> + if ((sd_flag & SD_BALANCE_FORK) && (idlest_sgs->idle_cpus && >> + !capacity_greater(idlest->sgc->max_capacity, group->sgc->max_capacity))) >> + return false; >> + } >> + >> /* Select group with lowest group_util */ >> if (idlest_sgs->idle_cpus == sgs->idle_cpus && >> idlest_sgs->group_util <= sgs->group_util) >> @@ -8940,7 +8948,7 @@ static bool update_pick_idlest(struct sched_group *idlest, >> * Assumes p is allowed on at least one CPU in sd. >> */ >> static struct sched_group * >> -find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu) >> +find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu, int sd_flag) >> { >> struct sched_group *idlest = NULL, *local = NULL, *group = sd->groups; >> struct sg_lb_stats local_sgs, tmp_sgs; >> @@ -8978,7 +8986,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu) >> >> update_sg_wakeup_stats(sd, group, sgs, p); >> >> - if (!local_group && update_pick_idlest(idlest, &idlest_sgs, group, sgs)) { >> + if (!local_group && update_pick_idlest(idlest, &idlest_sgs, group, sgs, sd_flag)) { >> idlest = group; >> idlest_sgs = *sgs; >> } >> -- >> 2.17.1 >>