Le 09/03/2014 00:03, David C. Rankin a écrit :
> Tim, All,
>
>    In working though testing, I used 'tdedebugdialog --fullmode' and set the '0
> generic' output to file kdebug.dbg (the default name) for all 4 (information,
> warning, error, etc). That file was over 46 Megabytes and 431,000 lines
> repeating tdepowersave activity in a 12 hour period. tdepowersave is constantly
> churning away in the following loop (2 examples):
>
> tdepowersave: unmonitored device changed: /sys/devices/
> tdepowersave: unmonitored device changed:
> /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3//dev/input/event3
> tdepowersave: unmonitored device changed:
> /sys/devices/LNXSYSTM:00/LNXSLPBN:00/input/input5/event4//dev/input/event4
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:03.0/net/enp0s3/enp0s3
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:04.0/input/input3/event2//dev/input/event2
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/input/input2/event1//dev/input/event1
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/i8042/serio0/input/input0/event0//dev/input/event0
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/i8042/serio1/input/input7/event6//dev/input/event6
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/pcspkr/input/input6/event5//dev/input/event5
> tdepowersave: unmonitored device changed: /sys/devices/
> tdepowersave: unmonitored device changed:
> /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3//dev/input/event3
> tdepowersave: unmonitored device changed:
> /sys/devices/LNXSYSTM:00/LNXSLPBN:00/input/input5/event4//dev/input/event4
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:03.0/net/enp0s3/enp0s3
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:04.0/input/input3/event2//dev/input/event2
> tdepowersave: unmonitored device changed:
> /sys/devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/input/input2/event1//dev/input/event1
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/i8042/serio0/input/input0/event0//dev/input/event0
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/i8042/serio1/input/input7/event6//dev/input/event6
> tdepowersave: unmonitored device changed:
> /sys/devices/platform/pcspkr/input/input6/event5//dev/input/event5
>
>    This is with the tde_dbus_hardwarecontrol happily set and not doing its
> repeating loop. Why is tdepowersave changing unmonitored devices multiple times
> per second? Is this just it spitting out what activity it read for various
> hardware devices (net, mouse, speaker)?? My mouse is usb, so I can see input
> there (not while I'm sleeping though), but why would any of the serial devices
> every change - they are not used. This looks like a true race condition, because
> none of my devices are changing, and they are certainly not changing multiple
> times every second while I'm asleep :)
>

Hello,

I've been instigating the CPU wasting issue in tdepowersave as well.
I've found out that the CPU cycles are mostly eaten by the TDEHW 
library, not in tdepowersave itself.

See: tdelibs/tdecore/tdehw/tdehardwaredevice.cpp

At line 244 and 246, you can see that there are 2 timers that are 
initialized.

The 1st timer is used to poll for CPU-related changes every 500ms.
It triggers a function line 409:
   void TDEHardwareDevices::processModifiedCPUs()

The 2nd timer ise used to poll other-devices changes every 1000ms.
It triggers a function line 740:
   void TDEHardwareDevices::processStatelessDevices()

After tracing, it looks like the 2nd timer is the most CPU-eating.
It basically rescans all hardware devices of the computer !

On the other side, as you have found, tdepowersave receives notification 
for every device in the system, and must filter the interesting one 
(cpu-related or battery-related).

I think there are 2 different solutions here:
1) find a way to remove the periodic polling and use notifications from 
kernel instead (but how ?)
2) optimize the polling code so that it eats less CPU


Francois