8 Mar
2014
8 Mar
'14
11:03 p.m.
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 :)
--
David C. Rankin, J.D.,P.E.
8 Mar
8 Mar
11:31 p.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
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
9 Mar
9 Mar
1:05 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
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:
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
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.
--
Slavek
3:07 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
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
12:18 p.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
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…
E. Liddell
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.
10 Mar
10 Mar
12:44 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
---- "E. Liddell" <ejlddll(a)googlemail.com> wrote:
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
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…
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.
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.
4:22 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
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
10:43 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
On Mon, 10 Mar 2014 04:22:22 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
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
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 :-)
1:11 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
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(a)yahoo.it> wrote:
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
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.
11 Mar
11 Mar
4:11 a.m.
New subject: [trinity-devel] tdepowersave - found new race condition (that explains the constant 3-5%)
---- "Slávek Banko" <slavek.banko(a)axis.cz> wrote:
On Sunday 09 of March 2014 13:18:37 E. Liddell wrote:
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.
On Sun, 9 Mar 2014 03:07:30 +0000 (GMT)
Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:
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
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.
3700
days inactive
3703
days old
9 comments
5 participants
participants (5)
-
David C. Rankin -
E. Liddell -
François Andriot -
Michele Calgaro -
Slávek Banko