Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7918361rdb; Thu, 4 Jan 2024 11:47:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IFyuYiem+R3nm7tqfrt3XAuiTE67FUQxPkh+YktwK/BLgoV/uU/YpUxxRUEHpUR/17UdqHk X-Received: by 2002:a17:902:c10c:b0:1d4:4fa3:2120 with SMTP id 12-20020a170902c10c00b001d44fa32120mr1065488pli.114.1704397661929; Thu, 04 Jan 2024 11:47:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704397661; cv=none; d=google.com; s=arc-20160816; b=UMWsw/isI/uTYvwMdGchSqorT5/1xy9t0+LY/HRUmcVNyGaQZD8rO1pO89Fkm0Gv8P ateEXbJudNAoRl206e098WDydhlkoOd3setqZg8oqnaFgbwbEq2UXaAzdgyRaVJo3QlD DXkMR/ou1aWF4mMzcdgBDUETYPoJg/vMi2rPvOVG8A8U49JwySE/yT0G4fRezryrrSzw IlPCsjXGm78RIba2jwAnIbruK9H0NJyuiHcOlUsw6lAlndZ+BUFi2AVgCwft3WS/LDkc 3sKMsMGL5M+bR4sP9ON8m3judonxbPVIaSh19JoxW72Idm/oIrbmlL81JwwO0X5Ft31B ch0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence; bh=9YPpasLIRq1YN3KdZH5r1q0RRJLitmfKfle8fM0qQes=; fh=O6YYF95gEoTquszwa1x1Mp3NZS9Am1klEUxdtkLeXmY=; b=BTX8Xnmbjs+OvgTuGGEm1dzuXA2YoSD72vVK8qKEZ0J2lpbyVlWrkbZtSO4H/vCfAx PLzLw8Bb58jPBwhwjHt+orWxR+ClqWqYATfoXCppnpykRHH90PW4pJkQFI5to4tMhZ+m 4ubE9ufl31OMuKRaqwHMRRcBPrci18MuviW5ka9tWZbZY8FNb9AD8kDp8uOogvrNxy0K ZNpcKVI/Vd/pNOgZ28Mhch4N/qmOVeFJcAOO8t29z07qb8VqKrpDyxUfr0fkilowHZyk lNkKDQG4oyF+p1I+Ywt6oBN2OIcBl2GreYZ5Wl0PahHRxDiMm+1ulsvnfw+fBGL4tFmy 1C1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17182-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17182-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id t8-20020a170902b20800b001d47f21d647si14208797plr.561.2024.01.04.11.47.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 11:47:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17182-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17182-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17182-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 908A7286DC3 for ; Thu, 4 Jan 2024 19:47:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7C26A2C1BF; Thu, 4 Jan 2024 19:47:33 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DDA32C19E; Thu, 4 Jan 2024 19:47:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-59629f0f67aso119115eaf.0; Thu, 04 Jan 2024 11:47:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704397650; x=1705002450; 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=9YPpasLIRq1YN3KdZH5r1q0RRJLitmfKfle8fM0qQes=; b=Sl/ITVYBcj4e+ovkmJfCuSNpX2thd5HXGrL6yKwXmj5g76rcHN+cyljqtZcNvSdDee Mivvfy0O0PB9/ZErx7YcG/e3uZPevD/4nIMhTbt/wWCUZF+iAr4cmPyxMLGQ0aLImwuD s6xluKkhEJb/NvgrPpBiM9YixCmR3M3WMayR8FJHhUVrLnwGFS4/ZjOg6VGGB0fOXCRN QpOJRCPj2A+TmblGx9QXWcHj0VBl/PcBKFXpsteEQZQhZTqUMPdHgIPl0ZcHGLHka1V5 Q0Ot507lcgyUy3Lcxbez4IJUJSymOhYz8XX011NPQ08QoKhDeTkIEA7H7MS0Hyprm2wR 4ciw== X-Gm-Message-State: AOJu0Yy9RMzXWJELJncRosfRoxe1iYjPz1HKf2DkWvtn1LG2f9gJn5Aa lf9WmFkHt/1CNwUUidoAO+zmJ0Dp7l/gVU1Obm4= X-Received: by 2002:a4a:e70a:0:b0:596:27ee:455d with SMTP id y10-20020a4ae70a000000b0059627ee455dmr1950518oou.0.1704397650649; Thu, 04 Jan 2024 11:47:30 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240104171553.2080674-1-lukasz.luba@arm.com> <20240104171553.2080674-12-lukasz.luba@arm.com> In-Reply-To: <20240104171553.2080674-12-lukasz.luba@arm.com> From: "Rafael J. Wysocki" Date: Thu, 4 Jan 2024 20:47:19 +0100 Message-ID: Subject: Re: [PATCH v6 11/23] PM: EM: Add API for updating the runtime modifiable EM To: Lukasz Luba Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org, dietmar.eggemann@arm.com, rui.zhang@intel.com, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't really like using the API TLA in patch subjects, because it does not really say much. IMO a subject like this would be better: "PM: EM: Introduce em_dev_update_perf_domain() for EM updates" On Thu, Jan 4, 2024 at 6:15=E2=80=AFPM Lukasz Luba wr= ote: > > Add API function em_dev_update_perf_domain() which allows to safely > change the EM. "... which allows the EM to be changed safely." New paragraph: > The concurrent modifiers are protected by the mutex > to serialize them. Removal of the old memory is asynchronous and > handled by the RCU mechanisms. "Concurrent updaters are serialized with a mutex and the removal of memory that will not be used any more is carried out with the help of RCU." > > Signed-off-by: Lukasz Luba > --- > include/linux/energy_model.h | 8 +++++++ > kernel/power/energy_model.c | 41 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 49 insertions(+) > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > index 753d70d0ce7e..f33257ed83fd 100644 > --- a/include/linux/energy_model.h > +++ b/include/linux/energy_model.h > @@ -183,6 +183,8 @@ struct em_data_callback { > > struct em_perf_domain *em_cpu_get(int cpu); > struct em_perf_domain *em_pd_get(struct device *dev); > +int em_dev_update_perf_domain(struct device *dev, > + struct em_perf_table __rcu *new_table); > int em_dev_register_perf_domain(struct device *dev, unsigned int nr_stat= es, > struct em_data_callback *cb, cpumask_t *s= pan, > bool microwatts); > @@ -376,6 +378,12 @@ struct em_perf_table __rcu *em_allocate_table(struct= em_perf_domain *pd) > return NULL; > } > static inline void em_free_table(struct em_perf_table __rcu *table) {} > +static inline > +int em_dev_update_perf_domain(struct device *dev, > + struct em_perf_table __rcu *new_table) > +{ > + return -EINVAL; > +} > #endif > > #endif > diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c > index bbc406db0be1..496dc00835c6 100644 > --- a/kernel/power/energy_model.c > +++ b/kernel/power/energy_model.c > @@ -220,6 +220,47 @@ static int em_allocate_perf_table(struct em_perf_dom= ain *pd, > return 0; > } > > +/** > + * em_dev_update_perf_domain() - Update runtime EM table for a device > + * @dev : Device for which the EM is to be updated > + * @table : The new EM table that is going to be used from now This is called "new_table" below. > + * > + * Update EM runtime modifiable table for the @dev using the provided @t= able. > + * > + * This function uses mutex to serialize writers, so it must not be call= ed "uses a mutex" > + * from non-sleeping context. "a non-sleeping context". > + * > + * Return 0 on success or a proper error in case of failure. It is not clear what "a proper error" means. It would be better to simply say "or an error code on failure" IMO. > + */ > +int em_dev_update_perf_domain(struct device *dev, > + struct em_perf_table __rcu *new_table) > +{ > + struct em_perf_table __rcu *old_table; > + struct em_perf_domain *pd; > + > + /* Serialize update/unregister or concurrent updates */ > + mutex_lock(&em_pd_mutex); > + > + if (!dev || !dev->em_pd) { dev need not be checked under the lock. > + mutex_unlock(&em_pd_mutex); > + return -EINVAL; > + } > + pd =3D dev->em_pd; > + > + em_table_inc(new_table); > + > + old_table =3D pd->em_table; > + rcu_assign_pointer(pd->em_table, new_table); > + > + em_cpufreq_update_efficiencies(dev, new_table->state); > + > + em_table_dec(old_table); > + > + mutex_unlock(&em_pd_mutex); > + return 0; > +} > +EXPORT_SYMBOL_GPL(em_dev_update_perf_domain); > + > static int em_create_runtime_table(struct em_perf_domain *pd) > { > struct em_perf_table __rcu *table; > --