Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp13068895rwb; Sat, 26 Nov 2022 22:15:46 -0800 (PST) X-Google-Smtp-Source: AA0mqf7RbM7AhvpwUCGZOrlZbh1qAKY+quCWcLt8e8SiTf+Ae5lR9tFpf4mP0tHuzXhgpvGWWghZ X-Received: by 2002:aa7:83d3:0:b0:56e:8477:1add with SMTP id j19-20020aa783d3000000b0056e84771addmr35389047pfn.13.1669529746216; Sat, 26 Nov 2022 22:15:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669529746; cv=none; d=google.com; s=arc-20160816; b=MZ1ROljV0XEV4nwEmUlWgOXuM+tdw/sEZ9Z2xiEHuFA6N43w0aGkrLFRStoNB2fHjF LQT6ZMAqsCASLUyJ0Uvn0Cqsa5WucyismLHPS0UEYIA40jZe/Ksf0mS6uT358zppv4ah v/AmfUmAy/2cpRwmLuOIux8bjUWwZBtn6ENqEG3ZrCbvXF2mmcCBXZdJawRPZEF7PUIH 6c3kzwVgXXT6MToe8+zZMt0KJjxz80Rlxkpp2dToVr+p6XYYupBnLaqqNC+fshqlzhJX OKrXxXYdzZo41Y4dDto3076YuYTZujStHBgzj/pQN3IuEF60yek9f6USk5oPfpVVqxNO cPgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=7hA1Z2uNzSMTWXrLl2LKV9tOjLPiiBES93P/TnmruM8=; b=ex5TUpRcTb9b3WoNhHu1YP2TLTOaysvlBIzI50D1Ymw3UMLjLhc8rJCTU7egTHwPKn hG7ZLtgjKCK8s8gqckXqNsqNlR2ineblyOVYx4tTyyR8ddFftEuctxp143OlDkMsMVe5 uAJoXCGp4nLsRDxmo1zcBdDWQ96mHLx4OlGBjsrKLgn8nTZrU0DVhYZn2QvDy7M0w0Cb wu7HzaIqm+uDz4iHpjiCFXBOZ0Fnvp65fVNC5W8A5UNDsAoyaMQ6b0JzF3JgPwT743f9 +FETrMAhrsk97BknsFnTk5xU7xdNBQsD8rSCINNOMUWd0HE0Daf70vXve4hgiZ/7bt20 0Ykw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KhXzznKr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d24-20020a17090ac25800b00212fb7e54ddsi7730444pjx.81.2022.11.26.22.15.35; Sat, 26 Nov 2022 22:15:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KhXzznKr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229535AbiK0DSz (ORCPT + 84 others); Sat, 26 Nov 2022 22:18:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229526AbiK0DSy (ORCPT ); Sat, 26 Nov 2022 22:18:54 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C285911171; Sat, 26 Nov 2022 19:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669519132; x=1701055132; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=xm7hkghGLyDEoxRiutr4crT1rjHd2FJh/KNtEHvMZQk=; b=KhXzznKrqR/4enr34t4erv5NuCyOXTMXJPC0+RwQRkIbB7Q2OnGKXyFZ pWQ5RUuin54wdWQ/o7/OwsZfG3fOTB3D0RchITg3ufC6sEoaWm4STWAH/ 5zaXgN9txIa5oLLhG/wGlXUgFmVsJmYEURzeHd1mCYcGy08lRwnMtLMmg UsMXae1et6DXavqwtU7m2le6SE7Y1CQ9ifdBPb8IiYsb2GlumqpUQMdgS QQHwzwgIPqYlvRTKrYG9ldX+lEuitOP1ICMP3x3UYnIMesqW+OuwZYXke FDRxkpC0fatkH1EGN7+vMcJDKosiWfSb/iB5EyhIEkZ1CHycxbEeii0L6 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10543"; a="341548007" X-IronPort-AV: E=Sophos;i="5.96,197,1665471600"; d="scan'208";a="341548007" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2022 19:18:52 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10543"; a="593530185" X-IronPort-AV: E=Sophos;i="5.96,197,1665471600"; d="scan'208";a="593530185" Received: from liyi4-mobl1.ccr.corp.intel.com ([10.254.214.186]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2022 19:18:50 -0800 Message-ID: <3e6c2e1d4008e70b14abc087c87bb80c78769011.camel@intel.com> Subject: Re: [RFC PATCH 2/3] cpuidle: ladder: Tune promotion/demotion threshold From: Zhang Rui To: "Rafael J. Wysocki" Cc: rjw@rjwysocki.net, daniel.lezcano@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Date: Sun, 27 Nov 2022 11:18:48 +0800 In-Reply-To: References: <20221105174225.28673-1-rui.zhang@intel.com> <20221105174225.28673-2-rui.zhang@intel.com> <5ed329f894bc81f5375303a69c07dee16630503e.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > I don't have a solid proof for this. But at least for the pure idle > > scenario, I don't think 30% deep idle residency is the right > > behavior, > > and it needs to be tuned anyway. > > Well, have you checked what happens if the counts are set to the same > value, e.g. 2? Well, this is embarrassing. I found a problem with my previous data when I re-evaluate following your suggestion. In short, 1. the 30% deep idle residency problem was got when I added some trace_printk() in the ladder_select_state() 2, without those trace_printk(), after patch 1, the ladder governor can still get 98% CPU%c7 in pure idle scenario. Currently, my understanding is that trace_printk() can call __schedule() and this increased the chance that call_cpuidle() returns immediately. When this happens, dev->last_residency_ns is set to 0 and results in a real demotion next time. Anyway, you are right on questioning this approach, because this seems to be a different problem or even a false alarm. So, I think I will submit patch 1/3 and 3/3 as they are bug fixes, and drop this patch for now, and leave the tuning work, if there is any, for the real ladder governor users. What do you think? thanks, rui