Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp4231530rdb; Mon, 11 Dec 2023 12:42:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IECPK003KqdJ/aUsMHOR1sP3M2hwlEBT7vr88pNqr9cSGpir6a0LC3WVsAETVkGUsE6tGGc X-Received: by 2002:a17:902:d386:b0:1d0:9c9d:dcdf with SMTP id e6-20020a170902d38600b001d09c9ddcdfmr5278890pld.39.1702327336989; Mon, 11 Dec 2023 12:42:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702327336; cv=none; d=google.com; s=arc-20160816; b=KnojivcrtiCj45sq18FBCd0CbF3vlft4Rdje4mvYoaCLepC/IK7JO9i2PfEHoC5VFB OM8YFSht2KP7w7OnBhgllbEY859HJ/zZNUHDw6lI16mg5wcOIddJkqhflZsXqF3kJZSH nzQ6MKT1DI+wGjSQL+Ws7RGmrLNxqfWdBZ2jYsM9dBpwmBGLayvvj3uTbC143VlYNNpQ DTePpcZm6LWE93byuK+0ay6IuHQ05AROy0PhV9xTvu0dSQMoOHUce40NWllkuAwWTgFy Ws8kmzi6oDr0ijZkQl5eBriSTPmpCw4oXnKWXpZpxwT6P1RNraWAFAKC7fmIMIJODha9 XhGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=9ih+j7IONlQ0zUFm+kXOTOE7rPVc4uGKGp9gEjKcXo0=; fh=wkSuoy5b1EIMGYEcqvfC1yBGuiIWNqkyE3KOqDLfZ9I=; b=PkTZlYA/XMGJI5cCSYXD+1hvB2RGxZNnVvm9/J+5cqRWNd8aq5GOJqrpuThg0HsB5L 7NqfFJhwFk4lfpZDWJqSEtmv2XtZyNVOWbeSj7+csoB6SiuxZKSJVtvlwP5rBZqULoGF fodP3I/td4dO1gpFV3cjJBS3Id8Ofh0PDk5LIzmV/WKuZ5+C3uOHoE4EeO0i+NgBX5aj LFSQshoH2r2rK17D7aJY1uREONL+GWDSWbCyPfzV4ZARx5oupDmXhedqIXOBY2krYXJn SFK1xoaqXNLaDetl/eOIOCCh4SBpmKOTmghLx9KJMl5fOxC3pm97CdiqNGhQrg7aMCrT HD4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id e18-20020a17090301d200b001d0a791c902si6302857plh.136.2023.12.11.12.42.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 12:42:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 862B7806290C; Mon, 11 Dec 2023 12:42:12 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344409AbjLKUl4 convert rfc822-to-8bit (ORCPT + 99 others); Mon, 11 Dec 2023 15:41:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbjLKUlz (ORCPT ); Mon, 11 Dec 2023 15:41:55 -0500 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14219D6; Mon, 11 Dec 2023 12:42:02 -0800 (PST) Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-6d9f4682c7bso411076a34.1; Mon, 11 Dec 2023 12:42:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702327321; x=1702932121; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Je421ZZjq5p+OuHl7zbDHQE6QhkT5uZwNBv6r9BGPzY=; b=iita/VpqC3r5v966kn4sjgi7dWUOLmmTvSBsEVSmn7/GKxTweQL52THyPt4d6xIOoc zibkzQaVfF8PRX4BddC/8/8oHk1kyYURpE3q9c6nR2Ajfgx0Ha4blTcX8RacQztor1A4 DaGl6Uk6ntbnkXFiKYehCl3qzfo8AZaLRyDxiqzr9aHKzyk7yfaEcG11kU62qx++46IB 5aB/Ry/FW1fxYZfw04x1eOLG8npu3/SKMo2mcI/1lKavJfy7x61AS0JUubt6LQhMphDE ra/7fli7d3btG0Ttg273o4HR0K6N5XZKuu5ej0tARYVQAX1F+EK7+HzMYJ7FyJmc5ZBs fBFQ== X-Gm-Message-State: AOJu0YwXA/Dz5fYErMoNBvE8KXfyOWi4eJ+X1P2RGI0f+YvwZffBN+TC yFEuljc/wUynbeJXWSKs/TSJSWX6t3AAy5Lt5bc= X-Received: by 2002:a05:6820:2d44:b0:58d:be0d:6f7b with SMTP id dz4-20020a0568202d4400b0058dbe0d6f7bmr8522288oob.1.1702327321245; Mon, 11 Dec 2023 12:42:01 -0800 (PST) MIME-Version: 1.0 References: <20231206113138.3576492-1-lukasz.luba@arm.com> <20231206113138.3576492-2-lukasz.luba@arm.com> In-Reply-To: <20231206113138.3576492-2-lukasz.luba@arm.com> From: "Rafael J. Wysocki" Date: Mon, 11 Dec 2023 21:41:50 +0100 Message-ID: Subject: Re: [PATCH 1/5] thermal: core: Add callback for governors with cooling instances change To: Lukasz Luba Cc: linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org, rafael@kernel.org, linux-pm@vger.kernel.org, rui.zhang@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 11 Dec 2023 12:42:12 -0800 (PST) On Wed, Dec 6, 2023 at 12:30 PM Lukasz Luba wrote: > > Allow governors to react to the changes in the cooling instances list. > That makes possible to move memory allocations related to the number of > cooling instances out of the throttle() callback. The throttle() callback > is called much more often thus the cost of managing allocations there is > an extra overhead. The list of cooling instances is not changed that often > and it can be handled in dedicated callback. That will save CPU cycles > in the throttle() code path. Both callbacks code paths are protected with > the same thermal zone lock, which guaranties the list of cooling instances > is consistent. > > Signed-off-by: Lukasz Luba I agree with the direction, but I'm wondering if changes of the bindings between trip points and cooling devices are the only type of changes which can affect the IPA. For instance, what if the trip point temperatures are updated? If it needs to react to other types of changes in general, it may be good to introduce a more general callback that can be made handle them in the future. > --- > drivers/thermal/thermal_core.c | 14 ++++++++++++++ > include/linux/thermal.h | 4 ++++ > 2 files changed, 18 insertions(+) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 625ba07cbe2f..c993b86f7fb5 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -314,6 +314,15 @@ static void handle_non_critical_trips(struct thermal_zone_device *tz, > def_governor->throttle(tz, trip); > } > > +static void handle_instances_list_update(struct thermal_zone_device *tz) > +{ > + > + if (!tz->governor || !tz->governor->instances_update) > + return; > + > + tz->governor->instances_update(tz); > +} > + > void thermal_zone_device_critical(struct thermal_zone_device *tz) > { > /* > @@ -723,6 +732,8 @@ int thermal_bind_cdev_to_trip(struct thermal_zone_device *tz, > list_add_tail(&dev->tz_node, &tz->thermal_instances); > list_add_tail(&dev->cdev_node, &cdev->thermal_instances); > atomic_set(&tz->need_update, 1); > + > + handle_instances_list_update(tz); > } > mutex_unlock(&cdev->lock); > mutex_unlock(&tz->lock); > @@ -781,6 +792,9 @@ int thermal_unbind_cdev_from_trip(struct thermal_zone_device *tz, > if (pos->tz == tz && pos->trip == trip && pos->cdev == cdev) { > list_del(&pos->tz_node); > list_del(&pos->cdev_node); > + > + handle_instances_list_update(tz); > + > mutex_unlock(&cdev->lock); > mutex_unlock(&tz->lock); > goto unbind; > diff --git a/include/linux/thermal.h b/include/linux/thermal.h > index c7190e2dfcb4..e7b2a1f4bab0 100644 > --- a/include/linux/thermal.h > +++ b/include/linux/thermal.h > @@ -195,6 +195,9 @@ struct thermal_zone_device { > * thermal zone. > * @throttle: callback called for every trip point even if temperature is > * below the trip point temperature > + * @instances_update: callback called when thermal zone instances list > + * i has changed (e.g. added new or removed), which > + * may help to offload work for governor like allocations > * @governor_list: node in thermal_governor_list (in thermal_core.c) > */ > struct thermal_governor { > @@ -203,6 +206,7 @@ struct thermal_governor { > void (*unbind_from_tz)(struct thermal_zone_device *tz); > int (*throttle)(struct thermal_zone_device *tz, > const struct thermal_trip *trip); > + void (*instances_update)(struct thermal_zone_device *tz); So this could be more general I think, something like (*update_tz)(), and it may take an additional argument representing the type of the change. > struct list_head governor_list; > }; > > -- > 2.25.1 >