Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp8166004rwd; Tue, 20 Jun 2023 11:03:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5pcoH1IFBpSYHjW7kaM5+aSLG3PggtxTAqbk6/DPF0M80dhB9nhZAG4YwAqBa3FiY6ipqg X-Received: by 2002:a05:6a20:841d:b0:10c:6dbc:2806 with SMTP id c29-20020a056a20841d00b0010c6dbc2806mr19652250pzd.46.1687284235780; Tue, 20 Jun 2023 11:03:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687284235; cv=none; d=google.com; s=arc-20160816; b=XB8GXq5oz5QVY67ms24VwywZic1vKVsG1l4N2AGygU5kRlKHgQ3SlKFOOPobxk/yda ST9W/bWZY67wWeUvmYF9+m/huyQV/YrGJs4SZcwe1ZvaqBvn26M9szdTndLdzDEGJYFy L+DKgvgZMrWwlQul+pGaIV6/2rD4K5xeRdig1TuOM4xgHWy4IYNpl/HjP4UkPNJ/6UXT UTSTqzOXY3NBnviQ6wOwyfhunf9n5v/xCLMfhK7ZxNe+Dr5oYAcQgGA5DTwv6xu0JH6U Wzh5jlqEB9Uso+K55/qOkhMVL/NxleFmf7H/gG1ZJjDvhzWFjwhV11KDrwg0ruy0ajd4 7idA== 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=ddP6cszizJeWYfw2AXGqairH0Dhmjc/4v3Y5sgJArFo=; b=NAJ2UGq1CyoWrdoxSdw+SS5IHh+tr1Akn/JpBGyG2EugsONv6nySquQN+34q9j6Xws FzdK6OgxmFkApAfljLKVrzfdxr3ize0WsRYYKF7GXp6Bfp4pl9B2HZbsbo2XVsJspcHL 3ypLOIgUGub9b8iz4HWixPdGASeiDdU4SafEyKThRD6qNk2OMuhS3TvbSyrii+TF061J CB5rcFydbIFdf61xBEBgpPFIINO/ZwePieTMv82QIa3S3TG28M4+LjDSbeu1WFmr3p9b pIz5w/tGVVVtYbCKY0dDOkSYuNzMsKgaHRro88mmbXmhLHmLxOZuUAY3riscQCr66Tv0 Lb1A== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i24-20020a633c58000000b0054b51fd23b5si2136717pgn.59.2023.06.20.11.03.43; Tue, 20 Jun 2023 11:03:55 -0700 (PDT) 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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229822AbjFTRNH convert rfc822-to-8bit (ORCPT + 99 others); Tue, 20 Jun 2023 13:13:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229605AbjFTRNG (ORCPT ); Tue, 20 Jun 2023 13:13:06 -0400 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C49C10E2; Tue, 20 Jun 2023 10:13:05 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-94ea38c90ccso150016366b.1; Tue, 20 Jun 2023 10:13:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687281184; x=1689873184; 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=2wpSEuA3rvhtFPmWePbVbFfYSViTlY0ARfPzV78qlSI=; b=fGpHMn6gMeGt5GHwp3S7yFkxbGl8RC3lKJL4yaWadkJlSIZ5GEWE/Xpi/C0brDfoVS kefo9fTkv2DI65Xc8E0N9jy237cbcFG/WEfu595fPIHjQVXj2tfi18hpRGINnNDyCQFi fiHCB2jsKygYHI+xMTnbxqKDavvF2X9/cqxdCNgJIx/oc5P/QTMgcIso11W0Vq3wIvqP 3wMTGykuNB6zcoyJSzA7G2O62UuA5hr7ZpYavC8ntXExazu907cAt7AbXnHXmINyFw0R XeC7qumeJxEwl8Ya+ZPu3FjcW3+pSnz687dTpFUNedi2y0Bp0by6xIuLA/nVkdsuuR3C Q0Kw== X-Gm-Message-State: AC+VfDyvkd5hLlrXdzWVpUxptEV/DCzRdXk5AoCTpIxUjNtv/54I8L13 Y8JMgLw2baaby+ar+YQh8f1NeAybkgk66v3B8qx7nDi4 X-Received: by 2002:a17:906:77ca:b0:989:1ed3:d010 with SMTP id m10-20020a17090677ca00b009891ed3d010mr2006867ejn.2.1687281183627; Tue, 20 Jun 2023 10:13:03 -0700 (PDT) MIME-Version: 1.0 References: <20230519032719.2581689-1-evalenti@kernel.org> <20230519032719.2581689-3-evalenti@kernel.org> In-Reply-To: <20230519032719.2581689-3-evalenti@kernel.org> From: "Rafael J. Wysocki" Date: Tue, 20 Jun 2023 19:12:52 +0200 Message-ID: Subject: Re: [PATCH 2/7] thermal: stats: track number of change requests due to tz To: Eduardo Valentin Cc: eduval@amazon.com, linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Daniel Lezcano , Amit Kucheria , Zhang Rui , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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 On Fri, May 19, 2023 at 5:27 AM Eduardo Valentin wrote: > > From: Eduardo Valentin > > This patch improves the current cooling device > statistics by adding a new file under > cdev/stats/requests_of_thermal_zone > > to represent the number of times each thermal zone > requested the cooling device to effectively change. > If the request associated was not serviced because > another thermal zone asked for a higher cooling level, > this counter does not increase. What if the cdev is associated with two thermal zones asking for the same state of it? > The file format is: > thermal_zone: > > Samples: > $ cat cdev0/stats/requests_of_thermal_zone > thermal_zone: amb0 2 The "one value per attribute" sysfs rule violation. > > In this example, it means the thermal zone 'amb0' has requested > 2 times for cdev0 to change state. Like in the previous patch, it would be good to explain the use case. > Cc: "Rafael J. Wysocki" (supporter:THERMAL) > Cc: Daniel Lezcano (supporter:THERMAL) > Cc: Amit Kucheria (reviewer:THERMAL) > Cc: Zhang Rui (reviewer:THERMAL) > Cc: Jonathan Corbet (maintainer:DOCUMENTATION) > Cc: linux-pm@vger.kernel.org (open list:THERMAL) > Cc: linux-doc@vger.kernel.org (open list:DOCUMENTATION) > Cc: linux-kernel@vger.kernel.org (open list) > > Signed-off-by: Eduardo Valentin > --- > .../driver-api/thermal/sysfs-api.rst | 2 + > drivers/thermal/thermal_core.h | 1 + > drivers/thermal/thermal_sysfs.c | 52 +++++++++++++++++++ > 3 files changed, 55 insertions(+) > > diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst > index caa50d61a5bc..75309a51d9b3 100644 > --- a/Documentation/driver-api/thermal/sysfs-api.rst > +++ b/Documentation/driver-api/thermal/sysfs-api.rst > @@ -369,6 +369,8 @@ Thermal cooling device sys I/F, created once it's registered:: > |---stats/trans_table: Cooling state transition table > |---stats/time_in_thermal_zone_ms: Time that this cooling device was driven > each associated thermal zone. > + |---stats/requests_of_thermal_zone: Total number of times this cooling device > + changed due to each associated thermal zone. The meaning of the above description is not clear to me. > > > Then next two dynamic attributes are created/removed in pairs. They represent > diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h > index 3cce60c6e065..ed6511c3b794 100644 > --- a/drivers/thermal/thermal_core.h > +++ b/drivers/thermal/thermal_core.h > @@ -103,6 +103,7 @@ struct thermal_instance { > unsigned int weight; /* The weight of the cooling device */ > bool upper_no_limit; > #if IS_ENABLED(CONFIG_THERMAL_STATISTICS) > + unsigned long total_requests; > ktime_t time_in; /* time spent in this instance */ > #endif > }; > diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c > index a3b71f03db75..0bce1415f7e8 100644 > --- a/drivers/thermal/thermal_sysfs.c > +++ b/drivers/thermal/thermal_sysfs.c > @@ -723,6 +723,7 @@ void thermal_cooling_device_stats_update(struct thermal_cooling_device *cdev, > stats->trans_table[stats->state * (cdev->max_state + 1) + new_state]++; > stats->state = new_state; > stats->total_trans++; > + stats->curr_instance->total_requests++; > > unlock: > spin_unlock(&stats->lock); > @@ -867,6 +868,54 @@ time_in_thermal_zone_ms_show(struct device *dev, struct device_attribute *attr, > return ret < 0 ? ret : len; > } > > +static ssize_t > +requests_of_thermal_zone_show(struct device *dev, struct device_attribute *attr, > + char *buf) > +{ > + LIST_HEAD(cdev_thermal_zone_list); > + struct thermal_cooling_device *cdev = to_cooling_device(dev); > + struct cooling_dev_stats *stats = cdev->stats; > + struct cdev_thermal_zone_residency *res, *next; > + struct thermal_instance *instance; > + ssize_t len = 0, ret = 0; > + > + mutex_lock(&cdev->lock); > + > + spin_lock(&stats->lock); > + update_time_in_state(stats, stats->curr_instance); > + spin_unlock(&stats->lock); > + > + build_cdev_thermal_zone_residency(&cdev_thermal_zone_list, cdev); > + > + list_for_each_entry(instance, &cdev->thermal_instances, cdev_node) > + list_for_each_entry(res, &cdev_thermal_zone_list, node) > + if (strncmp(res->thermal_zone, instance->tz->type, > + THERMAL_NAME_LENGTH) == 0) > + res->counter += instance->total_requests; > + > + mutex_unlock(&cdev->lock); > + > + list_for_each_entry_safe(res, next, &cdev_thermal_zone_list, node) { Why is the _safe variant needed here? > + ret = sprintf(buf + len, "thermal_zone: %s\t%lu\n", > + res->thermal_zone, res->counter); > + > + if (ret == 0) > + ret = -EOVERFLOW; > + > + if (ret < 0) > + break; > + > + len += ret; > + } > + > + list_for_each_entry_safe(res, next, &cdev_thermal_zone_list, node) { > + list_del(&res->node); > + kfree(res); > + } > + > + return ret < 0 ? ret : len; I would prefer if (ret < 0) return ret; return len; > +} > + > static ssize_t > reset_store(struct device *dev, struct device_attribute *attr, const char *buf, > size_t count) > @@ -897,6 +946,7 @@ reset_store(struct device *dev, struct device_attribute *attr, const char *buf, > > /* Make sure we reset all counters per instance */ > list_for_each_entry(instance, &cdev->thermal_instances, cdev_node) { > + instance->total_requests = 0; > instance->time_in = ktime_set(0, 0); > } > > @@ -971,6 +1021,7 @@ static ssize_t trans_table_show(struct device *dev, > static DEVICE_ATTR_RO(total_trans); > static DEVICE_ATTR_RO(time_in_state_ms); > static DEVICE_ATTR_RO(time_in_thermal_zone_ms); > +static DEVICE_ATTR_RO(requests_of_thermal_zone); > static DEVICE_ATTR_WO(reset); > static DEVICE_ATTR_RO(trans_table); > > @@ -978,6 +1029,7 @@ static struct attribute *cooling_device_stats_attrs[] = { > &dev_attr_total_trans.attr, > &dev_attr_time_in_state_ms.attr, > &dev_attr_time_in_thermal_zone_ms.attr, > + &dev_attr_requests_of_thermal_zone.attr, > &dev_attr_reset.attr, > &dev_attr_trans_table.attr, > NULL > --