From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: "Zhang, Rui" <rui.zhang@intel.com>
Cc: "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"srinivas.pandruvada@linux.intel.com"
<srinivas.pandruvada@linux.intel.com>,
"Brown, Len" <len.brown@intel.com>,
"stanislaw.gruszka@linux.intel.com"
<stanislaw.gruszka@linux.intel.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Neri, Ricardo" <ricardo.neri@intel.com>
Subject: Re: [PATCH 4/4] thermal: intel: hfi: Tune the number of CPU capabilities per netlink event
Date: Tue, 30 Apr 2024 18:16:29 -0700 [thread overview]
Message-ID: <20240501011629.GB29652@ranerica-svr.sc.intel.com> (raw)
In-Reply-To: <849b5bd75707433c6a7d9b854f8e3b5fd17dcba0.camel@intel.com>
On Tue, Apr 30, 2024 at 05:07:54AM +0000, Zhang, Rui wrote:
> On Mon, 2024-04-29 at 16:41 -0700, Ricardo Neri wrote:
> > The number of updated CPU capabilities per netlink event is hard-
> > coded to
> > 16. On systems with more than 16 it takes more than one thermal
> > netlink
> > event to relay all the new capabilities when processing an HFI
> > interrupt.
> > This adds unnecessary overhead.
> >
> > Make the number of updated capabilities per event tuneable via
> > debugfs.
> > Users can then experiment with different values.
> >
> Is there a limitation about the number of CPUs supported in one netlink
> event?
IIUC, the only limit is the size of the buffer for the message. intel_hfi
allocates the message based on the number of CPUs of the HFI instance.
>
> IMO, we still have to use a fixed number here because debugfs can be
> changed by someone else, and userspace application like intel-lpmd
> cannot make assumption that the netlink message follows what it set.
but you don't know how many messages with 16-CPUs payload you will receive
for a single update, no? Yes, you can infer it from the number of online
CPUs, but still.
But yes, now lpmd would receive an unknown number of messages with payloads
of unknown size.
>
> or can we append one magic item in the end of one update?
> userspace can just check the magic item no matter the number of CPU per
> netlink event.
AFAIK, only HFI and lmpd use the CPU capabilities thermal netlink message.
I guess it could be done.
prev parent reply other threads:[~2024-05-01 1:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 23:41 [PATCH 0/4] intel: thermal: hfi: Add debugfs files for tuning Ricardo Neri
2024-04-29 23:41 ` [PATCH 1/4] thermal: intel: hfi: Rename HFI_UPDATE_INTERVAL Ricardo Neri
2024-04-30 4:50 ` Zhang, Rui
2024-04-29 23:41 ` [PATCH 2/4] thermal: intel: hfi: Tune the HFI thermal netlink event delay via debugfs Ricardo Neri
2024-04-30 4:52 ` Zhang, Rui
2024-05-01 0:59 ` Ricardo Neri
2024-04-29 23:41 ` [PATCH 3/4] thermal: intel: hfi: Rename HFI_MAX_THERM_NOTIFY_COUNT Ricardo Neri
2024-04-29 23:41 ` [PATCH 4/4] thermal: intel: hfi: Tune the number of CPU capabilities per netlink event Ricardo Neri
2024-04-30 5:07 ` Zhang, Rui
2024-05-01 1:16 ` Ricardo Neri [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240501011629.GB29652@ranerica-svr.sc.intel.com \
--to=ricardo.neri-calderon@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=ricardo.neri@intel.com \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stanislaw.gruszka@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).