On 5/27/20 3:35 AM, Naveen Krishna Ch wrote: > Hi Alexander > > On Wed, 27 May 2020 at 12:29, Alexander Monakov <amonakov@xxxxxxxxx> wrote: >> >> On Wed, 27 May 2020, Naveen Krishna Ch wrote: >> >>> These registers are 32bit counters, they might wrap-around quite faster at >>> high work loads. So, we used a kernel thread to accumulate the values of >>> each core and socket to 64bit values. >>> >>> Depending on when the module is inserted in the system, the initial values >>> of the counters could be different and we do not have a way to know, how >>> many time the registers are wrapped around in the past. >> >> I understand that. If you anticipate that the module may be inserted after a >> wraparound, the driver should populate 'prev_value' with actual counter >> values instead of zeros. That way the driver will properly accumulate >> energy over time it's been inserted. As implemented, the driver counts >> energy since boot time, minus unknown amount lost to wraparounds if the >> driver was loaded too late. > No problem if this module is built into the kernel. > If this module is inserted at later point, unless the user keeps the > counters since > the boot and provide it as an input during the module insert (we can > implement this). I won't accept such a parameter. If you may recall, I did bring this up as reason why I abandoned the matching change for the coretemp driver, predicting that people would complain about it. Now they do. Not surprising. We (and you) will have to live with it. Guenter
