From: "Bills, Jason M" <jason.m.bills@linux.intel.com>
To: Ed Tanous <ed@tanous.net>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Sensor Value PropertiesChanged Events
Date: Tue, 2 Feb 2021 12:39:31 -0800 [thread overview]
Message-ID: <f6ed3a5f-2d4c-e554-400f-ba7caaae316e@linux.intel.com> (raw)
In-Reply-To: <CACWQX83KhqORsx-Gm4CCEndADO-GEgNHtxPpHR2ptsgzmtU9xA@mail.gmail.com>
On 2/1/2021 5:26 PM, Ed Tanous wrote:
> On Mon, Feb 1, 2021 at 4:44 PM Bills, Jason M
> <jason.m.bills@linux.intel.com> wrote:
>>
>> Hi All,
>>
>> There is an issue and idea that James Feist and I chatted about to maybe
>> relieve some of our D-Bus traffic.
>>
>> A major contributor to our D-Bus traffic (as seen in dbus-monitor) is
>> the polling sensors updating the xyz.openbmc_project.Sensor.Value.Value
>> property on each polling loop, which generates a PropertiesChanged
>> signal for every sensor on every polling loop (once per second?).
>>
>> The concern is that more important D-Bus messages could be getting
>> delayed as D-Bus processes these Sensor Value signals.
>>
>> The idea to fix this is to change the sensors with a custom getter on
>> the Value property, so the last read can be pulled from D-Bus using a
>> get-property call, but it would no longer signal a PropertiesChanged event.
>
> Doesn't this break..... like... everything that relies on sensor
> values changing over time?
I think this was my incorrect assumption that the PropertiesChanged
signal for sensor value updates was not used and could be removed
without significant impact. I will abandon my proposed change, but I'm
glad there are other thoughts and discussion around this issue.
Thanks!
-Jason
>
>>
>> I pushed a proposed change here:
>> https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/40199.
>>
>> Our original assumption was that nobody was matching on this
>> PropertiesChanged signal for the Value property; however, it was pointed
>> out to me today, that PID control has a match for it and may be using it.
>
snip...
next prev parent reply other threads:[~2021-02-03 2:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 0:42 Sensor Value PropertiesChanged Events Bills, Jason M
2021-02-02 1:26 ` Ed Tanous
2021-02-02 10:02 ` Ambrozewicz, Adrian
2021-02-04 15:55 ` Patrick Williams
2021-02-02 20:39 ` Bills, Jason M [this message]
2021-02-03 0:11 ` Andrew Jeffery
2021-02-03 1:28 ` Andrew Jeffery
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=f6ed3a5f-2d4c-e554-400f-ba7caaae316e@linux.intel.com \
--to=jason.m.bills@linux.intel.com \
--cc=ed@tanous.net \
--cc=openbmc@lists.ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.