<div dir="ltr">I've chatted with Patrick V. separately about the driver.  AST2400/2500 fan tach hardware measures only one fan at a time.  I think we can adjust the driver settings to reduce the measurement time but it will scale with # of tachs being read.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 5, 2017 at 9:34 AM, Patrick Williams <span dir="ltr"><<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, May 05, 2017 at 01:07:45AM -0400, Brad Bishop wrote:<br>
> > The solution that comes to mind would be to simply parallelize sensor<br>
> > updates, such that phosphor-hwmon uses threads to update the sensor<br>
><br>
> I think this is a great idea.  But I would vote for some kind of<br>
> non-blocking or async io rather than threads.  I don't know what support<br>
> for that sort of thing is available in the hwmon subsystem so I'm not<br>
> sure if its even possible, but it seems worth a look anyway.<br>
<br>
</span>If the IO operation within the hwmon kernel driver is taking 1 second, I<br>
don't think multi-threading does anything to improve this, except<br>
perhaps if you have two threads: 1 for dbus and 1 for hwmon polling.<br>
Going to N threads or N processes for the hwmon polling would not be<br>
beneficial since there would only be single driver queueing up the N<br>
threads anyhow.  Two threads just improves the dbus get-property<br>
response time for returning the cached value.<br>
<br>
Hopefully we can use sd-event with a non-blocking read on the hwmon<br>
sysfs entry to avoid having to resort to multi-threading.<br>
<br>
I don't know which device you are interacting with that is taking so<br>
long or how the driver was written, but a very common optimization in<br>
other hwmon drivers is to read all N hwmon registers from the device<br>
when the user touches any of the N sysfs entries and then cache them for<br>
a polling interval.  This would hopefully take your 8 seconds down to 1<br>
second for 8 devices.  Still pretty horrible if you are having to take 1<br>
second of kernel time for IO every <2 seconds.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Patrick Williams<br>
</font></span></blockquote></div><br></div>