Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4040220ybg; Fri, 25 Oct 2019 12:27:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzSGwqmNG0KgmL3hWLOXOeprI5pvAQ/B4azYlUwroIMcWwPe+XK7W2Y8gn5rI/aYQv+uxpE X-Received: by 2002:aa7:d714:: with SMTP id t20mr5886251edq.129.1572031645851; Fri, 25 Oct 2019 12:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572031645; cv=none; d=google.com; s=arc-20160816; b=JGJFLwuqDosMjh63DhfYEj0yNPXoF47tux+JLEuHR96dKWU2zDBO4dZ8iY99KzGxaf 0HT1gnj3LRVKYvNIArA/C3Ag+3efDhzVaa39unINQsixqDDKDEDGFIq21fykkdg5rMS6 z+fiVLi8a7JHrqksaiIDZI/7StcOQp3q9JoYposELiwyopZTPQb5mZxfu0nNsesuzGLt bGbKuyF15U/eLDcgnh2N4M54jPZwkJL8oS4TTIdT0ks3yE2HJiIIoCTKcrr1wAtKDAKu 7nPsuJjo4dRsY4fxZLtEUhGO9xRjPX2DamoQNdHVFcrhf+3GGslqbsNWfAsFzzSR39La TxNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date:from :references:cc:to:subject; bh=Yu/QPGGRxQl5I4cpVJqmuqn+8VptTPnI6h/VlvEMZmo=; b=ItzQTb/KYCJ54CAWCcbQQRmjnqDjoY51d8iPA9J0EEsY+/RAAuReVhskaWGoTAH+Vf s4FDfHX2bJ6ivsWQKptoE3BA/F/H21UniEjvvqFjQipkwjNIGy4xr77bCHqXR6oSCOI6 ENTlruycq/pSkWZDbUcDCVgnfr4kVuRX94Rr14fRFmWsdRQTZIESpRnphEPh+EMTku/G 2rVHLOKnkv29F7XqNRk5DMdFuIGion0caDWjRPcQv1qAOATE86K+PA1FU4TYRTnE0siw CLiz5tZ1iE56zHr6VjDbzkoOuEuhRUiJgirSVOnHjb6X/ZI7ChiAHEBA36W/a4AeMcp4 nb4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4si1895984edb.41.2019.10.25.12.27.02; Fri, 25 Oct 2019 12:27:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405345AbfJYGni (ORCPT + 99 others); Fri, 25 Oct 2019 02:43:38 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41610 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733071AbfJYGnh (ORCPT ); Fri, 25 Oct 2019 02:43:37 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x9P6bKT0100021 for ; Fri, 25 Oct 2019 02:43:36 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2vutkftd50-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 25 Oct 2019 02:43:36 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Oct 2019 07:43:34 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 25 Oct 2019 07:43:31 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x9P6hU4p54591684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Oct 2019 06:43:30 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E89FFA4051; Fri, 25 Oct 2019 06:43:29 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 60FE3A4053; Fri, 25 Oct 2019 06:43:28 +0000 (GMT) Received: from localhost.localdomain (unknown [9.124.35.242]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 25 Oct 2019 06:43:28 +0000 (GMT) Subject: Re: [PATCH] sched/fair: Make sched-idle cpu selection consistent throughout To: Viresh Kumar , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman Cc: linux-kernel@vger.kernel.org References: <5eba2fb4af9ebc7396101bb9bd6c8aa9c8af0710.1571899508.git.viresh.kumar@linaro.org> From: Parth Shah Date: Fri, 25 Oct 2019 12:13:27 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <5eba2fb4af9ebc7396101bb9bd6c8aa9c8af0710.1571899508.git.viresh.kumar@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 19102506-0028-0000-0000-000003AF3F33 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19102506-0029-0000-0000-0000247173F4 Message-Id: <7d3a1549-a99c-ae42-6074-8ed2ecd7074f@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-25_04:,, 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-1908290000 definitions=main-1910250062 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, On 10/24/19 12:15 PM, Viresh Kumar wrote: > There are instances where we keep searching for an idle CPU despite > having a sched-idle cpu already (in find_idlest_group_cpu(), > select_idle_smt() and select_idle_cpu() and then there are places where > we don't necessarily do that and return a sched-idle cpu as soon as we > find one (in select_idle_sibling()). This looks a bit inconsistent and > it may be worth having the same policy everywhere. > > On the other hand, choosing a sched-idle cpu over a idle one shall be > beneficial from performance point of view as well, as we don't need to > get the cpu online from a deep idle state which is quite a time > consuming process and delays the scheduling of the newly wakeup task. > > This patch tries to simplify code around sched-idle cpu selection and > make it consistent throughout. > > FWIW, tests were done with the help of rt-app (8 SCHED_OTHER and 5 > SCHED_IDLE tasks, not bound to any cpu) on ARM platform (octa-core), and > no significant difference in scheduling latency of SCHED_OTHER tasks was > found. > > Signed-off-by: Viresh Kumar > --- [...] > @@ -5755,13 +5749,11 @@ static int select_idle_smt(struct task_struct *p, int target) > for_each_cpu(cpu, cpu_smt_mask(target)) { > if (!cpumask_test_cpu(cpu, p->cpus_ptr)) > continue; > - if (available_idle_cpu(cpu)) > + if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) > return cpu; I guess this is a correct approach, but just wondering what if we still keep searching for a sched_idle CPU even though we have found an available_idle CPU? [...] Thanks, Parth