<div dir="ltr">Hi Ed,<div><br></div><div>I was talking about, if having one device in multiple daemons is expected, it would make sense to have some switch in the config to turn off the support for one device according to the setup. From your reply, I think I see this is not really preferred or expected from the design, so I'll leave it to Sui to come up with more data on the issue that we are having, and progress on the actual issue. In case the time is running out, we'll try local patches for workarounds. Thanks!</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Alex Qiu</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 6:42 PM Ed Tanous <<a href="mailto:ed@tanous.net">ed@tanous.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 11, 2020 at 5:46 PM Alex Qiu <<a href="mailto:xqiu@google.com" target="_blank">xqiu@google.com</a>> wrote:<br>
><br>
> The question was more of a general ask on whether dbus-sensors plans for this on record. If so, individual daemon should have the config option to ignore a device completely. Currently, I think PSUSensor has the ability, but HwmonTempSensor does not.<br>
><br>
<br>
You're talking about ignoring a specific leg of a device?  Like<br>
ignoring a particular sensor on an installed device?  Or are you<br>
talking about ignoring a device class entirely?  Maybe calling out the<br>
specific use case of what you're wanting to ignore might help here.<br>
<br>
> The reason behind it may be complicated. One is if we can fix the PSUSensor performance issue on time so that we can use it directly for PID control based on VR temperatures. And then, if we can't fix it on time, what work around can we have?<br>
<br>
I'm assuming "on time" here refers to some product schedule?  Without<br>
knowing your particular timelines, I will say this: we've solved<br>
several orders of magnitude worse performance problems in dbus sensors<br>
in the past.  I'm assuming this one just requires the proper<br>
application of debugging, thought, and engineering.  I'm not sure how<br>
to answer your question about workarounds:  You would have whatever<br>
workarounds you're willing to build, that's the beauty of open source.<br>
If using HwMonTempSensor is a workaround, and you're willing to live<br>
with the patch, by all means, use it.<br>
<br>
> Is it upstream-able or local patches<br>
<br>
That would depend on what your workarounds entail.  If your<br>
workarounds follow the principles of the project, don't duplicate<br>
functionality, don't break any of the existing use cases, and are<br>
maintainable, then they're probably upstreamable.  If you're<br>
duplicating features between daemons unnecessarily for lack of wanting<br>
to hunt down and understand a performance bug, that's probably<br>
something you need to keep in a local patch until you have time to do<br>
the appropriate debugging.<br>
<br>
> ? What's more, can we have different polling rates for temperature and voltage/current/power by using multiple daemon for the same device?<br>
<br>
Why don't we just make the polling rate configurable in the EM config?<br>
 Each sensor has its own timer for exactly this reason.  In the<br>
original design of dbus-sensors, each sensor instance also ran in its<br>
own process.  We moved it to each sensor type running in a shared<br>
process because the context switches were getting really bad, and a<br>
lot of the sensors of similar types had very similar event matches, so<br>
it allowed us to reduce the dbus load for things like power on.  We<br>
could certainly revisit this, but for what you're wanting, I suspect<br>
we can just configure the polling rates per sensor.  We hardcoded them<br>
under the assumption that we could build one reasonable default that<br>
worked for everyone, but clearly you've broken that assumption, so<br>
lets throw it in a config file, put some reasonable defaults on it,<br>
and call it good.  (note, this is subject to James' opinion as<br>
maintainer, I'm not sure if he'll agree here).<br>
<br>
> Of course, ideally, we can go for a fast feature-enriched PSUSensor to take care of everything and deprecate HwmonTempSensor, but you know I have been talking about schedule for multiple times with you before...<br>
><br>
<br>
I understand short schedules.  It always feels like there's not enough<br>
time.  The best advice I have here is to try to break your problem<br>
space down into small problems such that you can get a patch written,<br>
tested, and pushed to gerrit out for that day.  Then use those patches<br>
to slowly move toward what you want, even if you keep stacking them up<br>
in upstream.  Eventually the maintainer will review them, or you'll<br>
have solved someone else's problem before they hit it.  If enough<br>
people do this, we'll be way ahead on these types of bugs.<br>
<br>
At some point James might need to school us on what the theoretical<br>
difference is between PSUsensor and HwmonSensor.  I know one was<br>
originally built for PSU modules, and the other was built for on board<br>
hardware, but they're getting pretty similar, maybe it does make sense<br>
to have certain devices in both?<br>
</blockquote></div>