Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1078277yba; Thu, 4 Apr 2019 03:55:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZRKTtfejX54xtBE+Qld2OpIeir/xOyNF7aTFKzicaZEvKK7jbP5iZj7IULWhEstpQIugY X-Received: by 2002:a65:64cf:: with SMTP id t15mr5034517pgv.322.1554375344669; Thu, 04 Apr 2019 03:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554375344; cv=none; d=google.com; s=arc-20160816; b=RGb/+lD0UnFRsZ7J1BFKok451Xo5M/AOdruzTxYgFP2RjexIzWZg/4QLgrUUFoshOi 1MZv2Jv30wFRuKZ94AnFKr6X9HL6tjRb6JEE0D+RJb7PmOIE0bKbN5pHCC6udteOstKN ZBamjZie1qlQBvzemNGht/Xdqdu24Mw1vkjA6AAMlyXvVnLBaZuN7pLgSgjUGxs5kYn9 BKPXJVu42IK/FP/YX+ptfKzxts476wz6wIFSprcjprvtSdak+nmcHmRagXCab4Nr4i+N cUWHgfsiF26E0mKHLbKiCF1ZbQWcgTjWkeB1x0tB1VwT1ssQiTv0N/WwiOjwkVbjVpXj jpJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=mNKRYI724wU2ua8Lfa1mKNeq0ZvZ3joRQVVPoI0gIHI=; b=zkfVPLaRMSYXiAiZ9gj+pXCy0MF6EUs5bek3i+d8LsuIF5sue29e5clrXK3VWc6KDZ wIq0wTm5dxOiAC+SuwhNk/Wu5T2LQgPrXKw+xSNKdTl1BpunQCD22jqWiI9r7qmg3z4f Rfkbl4xDlYs6aw7nTf9b72juJtrLOglGkVyQ1BhfrkHkUwRZ/7crc1uvLw2X/0LAerlr 0wD9c1K8wv7Fq6vmdx2VYbwfJ/JdQk9HdBDW8qX6M7e80YsLHGx1iD+1Y/3hKOHKdY56 6ayPRh5Yzp38prp2/sYaAr5rOf3ckYpax9yH8OXdMZ9HYYGhir4BoBNF0WzCqWSUY2gw IytA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SAK16tvd; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l70si16181309pgd.242.2019.04.04.03.55.29; Thu, 04 Apr 2019 03:55:44 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SAK16tvd; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729626AbfDDKyt (ORCPT + 99 others); Thu, 4 Apr 2019 06:54:49 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:37170 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729277AbfDDKyt (ORCPT ); Thu, 4 Apr 2019 06:54:49 -0400 Received: by mail-oi1-f194.google.com with SMTP id v84so1498260oif.4; Thu, 04 Apr 2019 03:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=mNKRYI724wU2ua8Lfa1mKNeq0ZvZ3joRQVVPoI0gIHI=; b=SAK16tvdBcDUFOiK0AOv5qY8lw6iSQKIMVknSm5kIQ2HLk2oWFe8H2GCBXbdAy4Bt5 1K1EBPsFG6009u+vzyoYApZRjiTHgoX3h8sncYkoAekmA348v8d81miR5iIiNozYLVwu yc5Mf04canylWe5jgMF04goRQEvIm2ZB3R4ms1GJlnuzgQ6kB30SXNjXywKVcdlFkr7k Cd6phMUsUBD66OtGF1bZhTgXdYa+dY1aIz4y6Lzp6UVOXyPKhOq5ITIRMAjj+JgAxUsQ 5yV4euMkCBlOe8LHjhDuUD4oP3q2+77W5y5odj1x2VAtWfIejUsW9o2UyNIMvkVWi1K6 Okyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=mNKRYI724wU2ua8Lfa1mKNeq0ZvZ3joRQVVPoI0gIHI=; b=E07metHUYfj5vnIPqiRNiFjtuD1jRM+GrDnNjtuN158/6b/zIutVYHAQ0YAPZ4XnMo YNunzm7zx1IlMqZOtRWcV9D6jLYxCau9HDdKF266aEeibVhxO672oFJDPqJXetA92wAP Zp3QaUEN5IxvX7yuUGPXCD4mh2/84vgUn/oQ3LTjEkrP9PkBkIPPfoDMwfMFzNocwAd4 rifVPc0U34mRZK8kZA2RDS1Vr3pVhPDFC9qgHGDHrZi9Ur9nRaTRSoYT5lzixjs7d1/Y LfZnpqSBfo5a88JMuTry9cVgwoizKWTBeltlECjL2iIhleIX+c3u23/0fKVuWSZvOCRh Oq8Q== X-Gm-Message-State: APjAAAXvvBaNSSKc1NFQJTB5bW2yaCOLSABgj4FD/FohYVt900J6gPPL fB99po47txDxn4z2WlVHwvAyYLioMBdVextXnEo= X-Received: by 2002:aca:61d6:: with SMTP id v205mr2860978oib.122.1554375288745; Thu, 04 Apr 2019 03:54:48 -0700 (PDT) MIME-Version: 1.0 References: <20190322072942.8038-1-huntbag@linux.vnet.ibm.com> <20190322072942.8038-2-huntbag@linux.vnet.ibm.com> <50f62972-dfce-52bf-d26b-32e6d2a367e2@linux.vnet.ibm.com> <9e542011-df6d-9b84-823b-2af6a6ef9e94@linaro.org> In-Reply-To: <9e542011-df6d-9b84-823b-2af6a6ef9e94@linaro.org> Reply-To: ego@linux.vnet.ibm.com From: Gautham R Shenoy Date: Thu, 4 Apr 2019 16:24:37 +0530 Message-ID: Subject: Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states To: Daniel Lezcano Cc: Abhishek , "Rafael J. Wysocki" , "Rafael J. Wysocki" , linuxppc-dev , Linux Kernel Mailing List , Linux PM , ego@linux.vnet.ibm.com, Vaidyanathan Srinivasan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Daniel, On Thu, Apr 4, 2019 at 3:52 PM Daniel Lezcano wrote: > > > Hi Abhishek, > > thanks for taking the time to test the different scenario and give us > the numbers. > > On 01/04/2019 07:11, Abhishek wrote: > > [.. snip..] > > >>>> 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. > > I can understand an idle state can prevent other threads to use the core > resources. But why a deeper idle state does not prevent this also? On POWER9, we have the following classes of platform idle states (called stop states) lite : These do not lose any context including the user context. In this state GPRs are also preserved (stop0_lite) shallow : These lose user context,but not the hypervisor context. So GPRs are lost but not SPRs. (stop0, stop1, stop2) deep: These lose hypervisor context. (stop4, stop5) In the case of lite stop state, only instruction dispatch on the CPU thread is paused. The thread does not give up its registers set in this state for the use of its busy sibling threads in the core. Hence, SMT folding does not happen in this state. With respect to shallow and deep states, not only is the instruction dispatch paused, it also gives up its registers set for the other siblings to use These stop states are beneficial for SMT folding. Hence, if a CPU thread remains in a lite state for too long, its siblings in the core would not be able to utilize the full resources of the core for that duration, thereby inhibiting single thread performance. This is not the case with non-lite states. -- Thanks and Regards gautham.