phosphor-hwmon bottleneck potential
patrick at stwcx.xyz
Sat May 6 02:34:06 AEST 2017
On Fri, May 05, 2017 at 01:07:45AM -0400, Brad Bishop wrote:
> > The solution that comes to mind would be to simply parallelize sensor
> > updates, such that phosphor-hwmon uses threads to update the sensor
> I think this is a great idea. But I would vote for some kind of
> non-blocking or async io rather than threads. I don't know what support
> for that sort of thing is available in the hwmon subsystem so I'm not
> sure if its even possible, but it seems worth a look anyway.
If the IO operation within the hwmon kernel driver is taking 1 second, I
don't think multi-threading does anything to improve this, except
perhaps if you have two threads: 1 for dbus and 1 for hwmon polling.
Going to N threads or N processes for the hwmon polling would not be
beneficial since there would only be single driver queueing up the N
threads anyhow. Two threads just improves the dbus get-property
response time for returning the cached value.
Hopefully we can use sd-event with a non-blocking read on the hwmon
sysfs entry to avoid having to resort to multi-threading.
I don't know which device you are interacting with that is taking so
long or how the driver was written, but a very common optimization in
other hwmon drivers is to read all N hwmon registers from the device
when the user touches any of the N sysfs entries and then cache them for
a polling interval. This would hopefully take your 8 seconds down to 1
second for 8 devices. Still pretty horrible if you are having to take 1
second of kernel time for IO every <2 seconds.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the openbmc