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 :)
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
On Sunday 09 of March 2014 00:31:20 François Andriot wrote:
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:
- 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
Yes, that's exactly what I mentioned in other thread - mail http://trinity-devel.pearsoncomputing.net/?0::13193
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
I also think we should investingate option 1), even though I have no idea how to do that.
Michele
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT) Michele Calgaro michele.calgaro@yahoo.it wrote:
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
I also think we should investingate option 1), even though I have no idea how to do that.
I *think* we need to set up to receive notification signals from dbus, but most of the available documentation and examples are beyond my C programming weight class. The obvious place to start is dbus's own docs ( http://www.freedesktop.org/wiki/Software/dbus/#index4h1 ). There's also what seems to be an extensive example of signal creation and capture at http://maemo.org/development/training/maemo_platform_development_content/pla...
E. Liddell
---- "E. Liddell" ejlddll@googlemail.com wrote:
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT) Michele Calgaro michele.calgaro@yahoo.it wrote:
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
I also think we should investingate option 1), even though I have no idea how to do that.
I *think* we need to set up to receive notification signals from dbus, but most of the available documentation and examples are beyond my C programming weight class. The obvious place to start is dbus's own docs ( http://www.freedesktop.org/wiki/Software/dbus/#index4h1 ). There's also what seems to be an extensive example of signal creation and capture at http://maemo.org/development/training/maemo_platform_development_content/pla...
E. Liddell
Francios, Slavek, Michele, E.
Depending on the difficulty this fix requires, this may be one we want to fix before R14. It effects every install and the sheer volume of clock-cycles being consumed when TDE is sitting idle is alarming. Get Tim's input, but I think we need a bug report opened at either critical or blocker (you guys make the call). I'm in Colorado this week and have limited time over the next 6 days. I get the trinity-devel list, but my replies must be sent via my ISP's webmail interface (not good). Keep up the great work. Michele, if the consensus is to open a bug report on this one - can you do that this time?
-- David C. Rankin, J.D.,P.E.
Michele, if the consensus is to open a bug report on this one - can you do that this time?
Yep, no problem. As for me, this could impact TDE quite badly, so it would be reasonable to fix it before v14.0.0. Just waiting for other's opinions :-)
Michele
On Mon, 10 Mar 2014 04:22:22 +0000 (GMT) Michele Calgaro michele.calgaro@yahoo.it wrote:
Michele, if the consensus is to open a bug report on this one - can you do that this time?
Yep, no problem. As for me, this could impact TDE quite badly, so it would be reasonable to fix it before v14.0.0. Just waiting for other's opinions :-)
On the one hand, this is a new lib, growing pains are to be expected, and HAL is still available as a backup on many distros.
On the other hand, having a background process--any background process--consuming constant and significant CPU is not desirable.
This could be justifiably labeled as a blocker bug, I think, since it's going to degrade TDE's performance significantly on any distro not still shipping HAL.
That being said, Slavek is right--if in order to use notifications, we need to know what signals and devices need to be handled. Power management needs to know about AC being plugged in/unplugged and batteries being added/removed, I'd assume. For automounting, we'd need to capture a whole bestiary of events: plugging/unplugging of USB mass storage, sD and other similar cards, optical disks, floppies . . .
E. Liddell
On Sunday 09 of March 2014 13:18:37 E. Liddell wrote:
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT)
Michele Calgaro michele.calgaro@yahoo.it wrote:
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
I also think we should investingate option 1), even though I have no idea how to do that.
I *think* we need to set up to receive notification signals from dbus, but most of the available documentation and examples are beyond my C programming weight class. The obvious place to start is dbus's own docs ( http://www.freedesktop.org/wiki/Software/dbus/#index4h1 ). There's also what seems to be an extensive example of signal creation and capture at http://maemo.org/development/training/maemo_platform_development_content/pl ain_html/node6/
E. Liddell
You need to first make a list of "what to watch" and then find out "who will watch." We can not receive dbus signals until it is no one who send these signals :)
Already when I implemented the reading switches on the input event devices, I considered that monitoring could be carried out in tde_dbus_hardwarecontrol that would send dbus signals. But that would require first change way to refresh informations in tdehw-lib.
---- "Slávek Banko" slavek.banko@axis.cz wrote:
On Sunday 09 of March 2014 13:18:37 E. Liddell wrote:
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT)
Michele Calgaro michele.calgaro@yahoo.it wrote:
For input event devices such periodic rescan now represent dbus call to check the status of switches. Find ways to solution listed as 1) would be good.
I also think we should investingate option 1), even though I have no idea how to do that.
I *think* we need to set up to receive notification signals from dbus, but most of the available documentation and examples are beyond my C programming weight class. The obvious place to start is dbus's own docs ( http://www.freedesktop.org/wiki/Software/dbus/#index4h1 ). There's also what seems to be an extensive example of signal creation and capture at http://maemo.org/development/training/maemo_platform_development_content/pl ain_html/node6/
E. Liddell
You need to first make a list of "what to watch" and then find out "who will watch." We can not receive dbus signals until it is no one who send these signals :)
Already when I implemented the reading switches on the input event devices, I considered that monitoring could be carried out in tde_dbus_hardwarecontrol that would send dbus signals. But that would require first change way to refresh informations in tdehw-lib.
-- Slavek
At least from my original post on this thread, we know what it is looking at on my box. Is there some way I can dump additional information that would be helpful in this regard?
-- David C. Rankin, J.D.,P.E.
-
David C. Rankin -
E. Liddell -
François Andriot -
Michele Calgaro -
Slávek Banko