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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E1ACCD3423 for ; Tue, 19 Sep 2023 00:04:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230291AbjISAEv (ORCPT ); Mon, 18 Sep 2023 20:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230203AbjISAEu (ORCPT ); Mon, 18 Sep 2023 20:04:50 -0400 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0683297 for ; Mon, 18 Sep 2023 17:04:44 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-401d80f4ef8so56249715e9.1 for ; Mon, 18 Sep 2023 17:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1695081882; x=1695686682; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lKmKB9vKf9hesrksaYYza5X75bJdTltwCKlh53iy6pA=; b=VJTGOIhWTC+utVlvWwChb3XnHhljXNxCtg/Fs4DE19GxRyeSE3lVfXQhhGIpe6L/88 +MUywgwIpePapZJngHhPkwM2M9JT1oVD54T2CoPdNtURDuB4DK1WOy0kAr4Ebkvk5zHD TILNbuFhe4SoKh/MOT/98Xio8ZyZMu8IJozakR8n1QOFLCEEZaYPUZMsX9UGwDf6biI7 ZzE0A7gPBu7DaskGEe3+zD1c2V/T8NGLK4SJZhT6JhTUtzwWPvyuaXRQQ0H6f6m3NZJE pl0HD1FDL3qvxWTTgVQkenBQREHs2iB7SFzgApxEDqtMuySWviuwECAEvOguKu8Ys74W bdsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695081882; x=1695686682; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lKmKB9vKf9hesrksaYYza5X75bJdTltwCKlh53iy6pA=; b=ceDOobJfKyeaaE0j8EqRMMu9YzzcIs/C1R14UoHOio+pxcMVyxTkV9RELYiiRJ5oif qGRrsw6s90wbm8o0k7SY4FFMTDV4NRpNVP+XmC95zAcpg5YImLwTVnJOLz+4PFcuzLXW cSlMR7BbybzeerVQmyIgfcYA6RnuT67WAFQgQsUI/hfHlZnSmNlHZttSf0tuuTGcxHpr yNsNGw+S7DzlZamXcslJyo1KRrmQMpdB3RD0em1XV1G0jc0ktku/ZdEu2WkcafsunqKu DdOqeFZ2Z22Wb9FqTTDuFw1+SAMXUwL/LPeeRBMZ6BspwrDNP8rNmSra6V1Hz03x5NOY mSgw== X-Gm-Message-State: AOJu0YwlS0bK56+7kNNLs5oKyLSmTQ3LKyOyoa1Y/jCeqkzHNKxc8e69 UyK64a3pVvkjExDCtNapHIfFVQ== X-Google-Smtp-Source: AGHT+IFFNKYAqa2w2v6F9Nsoh+8X0Rmm4dO2+giDMVqp6b0lA5AFGb6pjPhsq9KnLzYuiV/4dGOdfA== X-Received: by 2002:a5d:4591:0:b0:31f:e418:223d with SMTP id p17-20020a5d4591000000b0031fe418223dmr7716962wrq.7.1695081881961; Mon, 18 Sep 2023 17:04:41 -0700 (PDT) Received: from airbuntu (host109-151-228-137.range109-151.btcentralplus.com. [109.151.228.137]) by smtp.gmail.com with ESMTPSA id r2-20020adfe682000000b0031fe0576460sm4223971wrm.11.2023.09.18.17.04.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 17:04:41 -0700 (PDT) Date: Tue, 19 Sep 2023 01:04:40 +0100 From: Qais Yousef To: Kajetan Puchalski Cc: rafael@kernel.org, daniel.lezcano@linaro.org, lukasz.luba@arm.com, Dietmar.Eggemann@arm.com, dsmythies@telus.net, yu.chen.surf@gmail.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Peter Zijlstra Subject: Re: [PATCH v6 2/2] cpuidle: teo: Introduce util-awareness Message-ID: <20230919000440.fq5nyttc4mgpou7x@airbuntu> References: <20230105145159.1089531-1-kajetan.puchalski@arm.com> <20230105145159.1089531-3-kajetan.puchalski@arm.com> <20230711175814.zfavcn7xn3ia5va4@airbuntu> <20230718132432.w5xoxbqm54jmu6n5@airbuntu> <20230917010516.54dgcmms44wyfrvx@airbuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 09/18/23 12:41, Kajetan Puchalski wrote: > Yes very much agreed on this part, they definitely can be improved. I'm > currently exploring some other approaches to this issue as well but > that's more of a long-term thing so it'll likely take a couple of months > to see whether they're workable or not. Sounds good :) > The role I think the util bits are supposed to play here is mainly to > give us a view from a bit higher up than the metrics themselves do > because of how quickly those decay. Another way to do it would be some > way to make the threshold self-adjusting in the same way the metrics > are, e.g. increase the threshold if we're suddenly hitting too many too > shallow sleeps and decrease when we're hitting too many deep sleeps as a > result of the util checks. This would take care of the edge cases > currently falling through the cracks of their util being right around the > threshold, the mechanism would adjust within a few seconds of a workload > like video playback running. Could be a step in the right direction at least. I'm not keen on the 'too many' part personally. It does feel finger in the air to me. But maybe it can work. Beside timers, tasks wake up on synchronization mechanisms and IPC, we can potentially gather more info from there. For example, if a task is blocked on a kernel lock, then chances its in kernel contention and it supposed to wake up soon for the kernel to finish servicing the operation (ie: finish the syscall and return to user mode). Android has the notion of cpus being in deeper idle states in EAS. I think we could benefit from such thing in upstream too. Not all idle cpus are equal when idle states are taken into account, for both power and latency reasons. So there's room to improve on the wake up side to help keep CPUs in deeper idle states too. Load balancer state can give indications too. It'll try to spread to idle CPUs first. Its activity is a good indication on the demand for an idle CPU to be ready to run something soon. Generally maybe scheduler and idle governor can coordinate better to provide/request some low latency idle CPUs, but allow the rest to go into deeper idle states, per TEO's rule of course. On HMP systems this will be trickier for us as not all CPUs are equal. And cluster idle can complicate things further. So the nomination of a low latency CPU needs to consider more things into account compared to other systems (except NUMA maybe) where any idle CPU is as good as any other. Thanks! -- Qais Yousef