Eeprom driver optimization

Jean Delvare khali at
Sat Aug 23 20:59:18 CEST 2003

> I would suggest that the chance of eeprom contents changing during
> normal running is *very* small.
> Therefore, you could set the refresh time to be *very* long by default
> (and make it configurable if the VAIO BIOS is changing the eeprom
> underneath us. Gosh I hope not...)  Say 10 minutes or more.  Then read
> the contents once, and cache the results.

That solves the further reads, agreed. But that's not my concern here.
What I'm trying to enhance here is the initial read time. It may sound
pointless because it's only the first time, but I believe it's important
because that's how much the users have to wait the first time they run
sensors. We *know* that it's longer than further calls, but the user

> An alternative would be to just divide the eeprom into 16-byte subsets
> and assign a refresh timer to each.  This matches the /proc
> organization pretty well. (16 bytes per file)

Great, that's almost the solution I went to. Since I was offline while
working on the problem, I took some notes. Here they are:


Here are the rows that are accessed by sensors (I start counting with
row 1):
sensors::vaio   : 9-10, 13-14
sensors::*      : 1
sensors::edid   : 1
sensors::dimm   : 1-2

Here are the rows that are accessed by our various scripts:  : 1 (failure) 1-8 (success)  : 2-3, 9-11, 13-16 : 1-4 (failure) 1-8 (success)  : 1-6, 8

5 strategies

1* No partitioning (as it was before).
   Module size: 3616 bytes (before optimization 1).
   Sensors time (dimm): 2.58s.
   Sensors time (vaio): 2.58s.

2* Smart partitioning (2-2-4-8).
   Per-eeprom memory overhead: 12 bytes.
   Module size: 3456 bytes (before optimization 2).
   Sensors time (dimm): 0.34s.
   Sensors time (vaio): 1.30s.

3* Sensors-oriented partitioning.
   Zone 1 = row 1
   Zone 2 = row 2
   Zone 3 = rows 9-10
   Zone 4 = rows 13-14
   Zone 0 = everything
   Per-eeprom memory overhead: 16 bytes.
   Not tested.

4* Raw partitioning, 1-row slices.
   No zones, sub-partitioning of solution #5 (and therefore of #2).
   Per-eeprom memory overhead: 61 bytes.
   Doesn't significantly speed sensors up (compared with solution #5).
   Not tested.

5* Raw partitioning, 2-row slices.
   No zones, sub-partitioning of solution #2.
   Per-eeprom memory overhead: 28 bytes.
   Module size: 3424 bytes.
   Sensors time (dimm): 0.34s.
   Sensors time (vaio): 0.67s.

Notes about optimizations:
Optimization 1 is removing the big switch/case in the callback function,
and use the sysctl value instead. Faster, cleaner.
Optimization 2 is seeing valid as a bit vector instead of an array.


The version I'll commit to the CVS repository is solution #5. It seems
to be the best speed/memory tradeoff, doesn't depend on a specific use
of eeproms, and is rather straightforward to understand.

The speed improvement is simply amazing, so I guess everyone will like
the change. It would make it possible to lower the buffering time (5
minutes for now), which will be interesting if we want to support write
to eeproms.

(OT: It looks like my I2C bus is working at 2 kHz. Isn't it too slow?
Most chips I've read the datasheets of don't accept running below 10

> But since sysfs is coming soon and Greg KH's proposal is a single
> binary file for eeprom's, I think my first suggestion is better for
> the future...

This raises two questions:

1* Is a monoblock file the best idea? It prevents any speed
optimisation. However, it makes handling easier for sure. Also, what
will be the file size? For now, we don't detect the eeprom size, and I
don't think we can really detect it. Module parameter?

2* Should eeproms be supported by sensors? Eeproms are not sensors. If
we opt for a monoblock file, they will be slow displaying (at least the
first time) as before. And people don't care about them (at least when
running sensors). So I'd suggest we remove eeprom from sensors, and/or
remove it from sensors-detect (so that people get it only if they really
want it). I'd prefer removing eeprom from sensors, so that people can
still load the modules and use the various scripts to get the values
from the eeproms in a much better form than when using sensors. We would
maintain support into libsensors, so that people needing to access the
eeproms have an easy way to do so.

Jean Delvare

More information about the lm-sensors mailing list