From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1838C7618B for ; Thu, 25 Jul 2019 07:09:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 90F6D20840 for ; Thu, 25 Jul 2019 07:09:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729594AbfGYHJP (ORCPT ); Thu, 25 Jul 2019 03:09:15 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59664 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729581AbfGYHJP (ORCPT ); Thu, 25 Jul 2019 03:09:15 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6P76ZbL067198 for ; Thu, 25 Jul 2019 03:09:13 -0400 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ty4tpq2rx-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Jul 2019 03:09:13 -0400 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 25 Jul 2019 08:09:11 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 25 Jul 2019 08:09:08 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6P797BT57475280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jul 2019 07:09:07 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3AC104C058; Thu, 25 Jul 2019 07:09:07 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B8D444C04A; Thu, 25 Jul 2019 07:09:05 +0000 (GMT) Received: from localhost.in.ibm.com (unknown [9.124.35.169]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 25 Jul 2019 07:09:05 +0000 (GMT) From: Parth Shah To: peterz@infradead.org, mingo@redhat.com Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, patrick.bellasi@arm.com, dietmar.eggemann@arm.com, daniel.lezcano@linaro.org, subhra.mazumdar@oracle.com Subject: [RFC v4 4/8] sched/fair: Define core capacity to limit task packing Date: Thu, 25 Jul 2019 12:38:53 +0530 X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190725070857.6639-1-parth@linux.ibm.com> References: <20190725070857.6639-1-parth@linux.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 19072507-0012-0000-0000-00000335FA97 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19072507-0013-0000-0000-0000216F910E Message-Id: <20190725070857.6639-5-parth@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-25_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907250085 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Define a method name arch_scale_core_capacity which should return the capacity of the core. This method will be used in the future patches to determine if the spare capacity is left in the core to pack jitter tasks. For some architectures, core capacity does not increase much with the number of threads (or CPUs) in the core. For such cases, architecture specific calculations needs to be done to find core capacity. In addition to this, provide a default implementation for the scaling core capacity. ToDo: As per Peter's comments, if we are getting rid of SMT capacity then we need to find a workaround for limiting task packing. I'm working around that trying to find a solution for the same but would like to get community response first to have better view. Signed-off-by: Parth Shah --- kernel/sched/fair.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b798fe7ff7cd..793e1172afc7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5964,6 +5964,25 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t return cpu; } +#ifdef CONFIG_SCHED_SMT + +#ifndef arch_scale_core_capacity +static inline unsigned long arch_scale_core_capacity(int first_thread, + unsigned long smt_cap) +{ + /* Default capacity of core is sum of cap of all the threads */ + unsigned long ret = 0; + int sibling; + + for_each_cpu(sibling, cpu_smt_mask(first_thread)) + ret += cpu_rq(sibling)->cpu_capacity; + + return ret; +} +#endif + +#endif + /* * Try and locate an idle core/thread in the LLC cache domain. */ -- 2.17.1