Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp419134img; Fri, 22 Mar 2019 00:32:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqydc2XZHKG0e6HoVM2ez+cUxVTm2vqe0RuoyDT6mn6bKIVIexTMcCA9Hmld/msVk3gFzpND X-Received: by 2002:a62:bd13:: with SMTP id a19mr7687837pff.222.1553239946347; Fri, 22 Mar 2019 00:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553239946; cv=none; d=google.com; s=arc-20160816; b=OPH25wVwuS0xVCcqaNL4LsHqKJh6ift5NvHgmU5hFsSQL8I9QmZ2zdaaDWMzoctTzX Xfhx0kr7vI1FgCg45xONLk5OJXEaJJiNWNjsE7QYM0CEMMICKDNq24Fb71j9CWboStqW ajNRaopXdcZYifkwi2SsQwaJtyPPQqIS1xKa7AMJ2jL2y9e11mWWVll877gDi3qGcU/O /kfKsPa3FILlozq4/OoLZrvXyOzR24Kvyc6qQVLqGD+UtopSzN+piugIqIeAM4c0LdPL 1yUt0wKO/A5ycnYe7xUPRdKqKU3pIB0MVXSY/pRyVx/R3zLKDuu3S+zmp3FWp8mHZDnr MwxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=Unj1CEktj+yCeqkbARWdNJfO6lHG5+97VF7oOVAiMpM=; b=GDfmoaABbpe/JKxnfvIID8o84RzuwG/lwL8fFxlGQeD4Mo+KZtRyRLRwLK6ZBOLkM5 TdWDLxcuX2WpmXDFrgOExx7HwYdZAiULl7BMJqaEsjjuBKqSMK7+oX/9HDQP3XHo2dAj FO7Mgma4EDaZCXz82Ln9+wfut14S2MqZ+1n42Bccc8zckGXlYfGS8Fvf4AYQ30B+3byK eGh76ArgFseeKH0gaLs/+hczsCC+e8TA5XL3xK+7LdQ1edcP3VW+z0wfRTTFhX9iVV8y PgFlY9GHOs8UA5ColCC1OwDIMVEuTkAY+f/FVR7LybA3m8lFe8SIjiN6cLRX9dRvY2T3 w2xQ== 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 n7si6335034plk.85.2019.03.22.00.32.09; Fri, 22 Mar 2019 00:32:26 -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 S1726543AbfCVHbc (ORCPT + 99 others); Fri, 22 Mar 2019 03:31:32 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36488 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbfCVHbb (ORCPT ); Fri, 22 Mar 2019 03:31:31 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2M7O6Yp074820 for ; Fri, 22 Mar 2019 03:31:30 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rcu3f0t7v-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 22 Mar 2019 03:31:30 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 22 Mar 2019 07:31:26 -0000 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, 22 Mar 2019 07:31:23 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x2M7VOP022085792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Mar 2019 07:31:24 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E039F11C05B; Fri, 22 Mar 2019 07:31:23 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C422C11C064; Fri, 22 Mar 2019 07:31:22 +0000 (GMT) Received: from boston16h.aus.stglabs.ibm.com (unknown [9.3.23.78]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 22 Mar 2019 07:31:22 +0000 (GMT) From: Abhishek Goel To: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-pm@vger.kernel.org Cc: rjw@rjwysocki.net, daniel.lezcano@linaro.org, mpe@ellerman.id.au, Abhishek Goel Subject: [PATCH 0/2] Auto-promotion logic for cpuidle states Date: Fri, 22 Mar 2019 02:29:40 -0500 X-Mailer: git-send-email 2.17.1 X-TM-AS-GCONF: 00 x-cbid: 19032207-0028-0000-0000-00000356F672 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19032207-0029-0000-0000-000024159FD6 Message-Id: <20190322072942.8038-1-huntbag@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-22_05:,, 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=535 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903220057 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, the cpuidle governors (menu/ladder) determine what idle state a idling CPU should enter into based on heuristics that depend on the idle history on that CPU. Given that no predictive heuristic is perfect, there are cases where the governor predicts a shallow idle state, hoping that the CPU will be busy soon. However, if no new workload is scheduled on that CPU in the near future, the CPU will end up in the shallow state. Motivation ---------- In case of POWER, this is problematic, when the predicted state in the aforementioned scenario is a lite stop state, as such lite states will inhibit SMT folding, thereby depriving the other threads in the core from using the core resources. To address this, such lite states need to be autopromoted. The cpuidle-core can queue timer to correspond with the residency value of the next available state. Thus leading to auto-promotion to a deeper idle state as soon as possible. Experiment ---------- Without this patch - It was seen that for a idle system, a cpu may remain in stop0_lite for few seconds and then directly goes to a deeper state such as stop2. With this patch - A cpu will not remain in stop0_lite for more than the residency of next available state, and thus it will go to a deeper state in conservative fashion. Using this, we may spent even less than 20 milliseconds if susbsequent stop states are enabled. In the worst case, we may end up spending more than a second, as was the case without this patch. The worst case will occur in the scenario when no other shallow states are enbaled, and only deep states are available for auto-promotion. Abhishek Goel (2): cpuidle : auto-promotion for cpuidle states cpuidle : Add auto-promotion flag to cpuidle flags arch/powerpc/include/asm/opal-api.h | 1 + drivers/cpuidle/Kconfig | 4 ++ drivers/cpuidle/cpuidle-powernv.c | 13 ++++- drivers/cpuidle/cpuidle.c | 79 ++++++++++++++++++++++++++++- drivers/cpuidle/governors/ladder.c | 3 +- drivers/cpuidle/governors/menu.c | 23 ++++++++- include/linux/cpuidle.h | 12 +++-- 7 files changed, 127 insertions(+), 8 deletions(-) -- 2.17.1