Bug 289462

Do you use any third-party script?

No, I.m using de default packages and configuration from Fedora 17 (rawhide). I didn't even know that you can use third party scripts :-)

Martin Kho

Thank you for the feedback.

Same here on xubuntu 11.10 with amarok 2.4.3 and 2.5. On my slightly older machine the CPU usage amounts to: dbus-daemon: 3-5%, amarok: 1.7-2.7%, udisk-daemon: 1-2%.
Note the 'idle' cpu usage of amarok itself. This is with an empty playlist, amarok stopped (not paused), all applets but 'current track' disabled, all (default) scripts disabled, watch folders disabled.

Confirmed.

Finally somebody reported the problem not only on mailing list :-). I have the same problem for a long time now, currently I'm using Amarok 2.4.3. When doing nothing (minimized, not playing), it eats ~3% of the CPU, dbus-daemon (~3%CPU) plus udisks-daemon (~2%CPU), eating in total 8% of CPU time.

Rick, since you have worked on that before, could you please look into this?

Can you use 'dbus-monitor' and see what might be causing the spam please.

Hi Rick,

[OT] What a nice restyling of kde bugzilla :-)

I've tried running dbus-monitor as you requested, but it gave me nothing that's related to udisks/dbus daemons. Sorry. Any other thoughts?

Martin Kho

Still trying to understand dbus-monitor output ... But I think it's worth mentioning that in my case the system dbus (messagebus) is concerned, although dbus-monitor --system gives very few output. This may be a hint that the issue with the udisks-daemon and the dbus-daemon are correlated (e.g. how gets amarok informed about new externel drives, mtp devices, etc.).

the problem is in the MediaDeviceCache::slotTimeout() slot, every second it lists all Solid::Device::listFromType( Solid::DeviceInterface::StorageAccess ); and that does a dbus call to udisks (hence dbus and udisks CPU usage)
#15 0x00007f0d8a9e286a in Solid::Device::listFromType (type=@0x7fff83b579c8, parentUdi=...) at /usr/src/debug/kdelibs-4.7.2/solid/solid/devicemanager.cpp:112
#16 0x00007f0d8f8fe463 in MediaDeviceCache::slotTimeout() () from /usr/lib64/libamaroklib.so.1

strace of udisks:
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\1\0\0010\0\0\0\230\t\0\0\217\0\0\0\1\1o\0\27\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 208
recvmsg(3, 0x7fff5b0a9f80, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=8, events=POLLPRI}, {fd=10, events=POLLIN}, {fd=11, events=0}, {fd=3, events=POLLIN}], 5, 0) = 0 (Timeout)
sendmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"l\3\1\1\35\0\0\0\25\367\1\0O\0\0\0\6\1s\0\6\0\0\0:1.597\0\0"..., 96}, {"\30\0\0\0No such property IdUsage\0", 29}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 125
poll([{fd=5, events=POLLIN}, {fd=8, events=POLLPRI}, {fd=10, events=POLLIN}, {fd=11, events=0}, {fd=3, events=POLLIN}], 5, 1670538) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\1\0\1\0\0\0\0\232\t\0\0\227\0\0\0\1\1o\0#\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 168
recvmsg(3, 0x7fff5b0a9f80, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=8, events=POLLPRI}, {fd=10, events=POLLIN}, {fd=11, events=0}, {fd=3, events=POLLIN}], 5, 0) = 0 (Timeout)
sendmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"l\3\1\1K\0\0\0\26\367\1\0O\0\0\0\6\1s\0\6\0\0\0:1.597\0\0"..., 96}, {"F\0\0\0First argument to Get(), Get"..., 75}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 171

the answers of udisks seem to indicate errors to me, somebody familiar with that should have a look at that if possible!
some version info:
udisks-1.0.4-2.4.1.x86_64
christophnb:~ # rpm -qa|grep kdelibs
kdelibs3-3.5.10-52.1.2.x86_64
kdelibs4-4.7.2-5.2.2.x86_64
kdelibs4-doc-4.7.2-5.2.2.x86_64
kdelibs3-default-style-3.5.10-52.1.2.x86_64
kdelibs4-core-4.7.2-5.2.2.x86_64
kdelibs4-branding-openSUSE-12.1-15.3.9.noarch

I can confirm the bug. Amarok eats my rather old CPU while do nothing, up to 10%

There's now a patch at https://git.reviewboard.kde.org/r/105221/ that removes the polling. It is rather a risky one so I won't push it for 2.6, but please test it nontheless. Specifically, it may have some side-effects on detection of media devices (only MTP and CDs) and "dynamic collection" feature. (automatic detection of Local Collection folders on removable media & network filesystems appearing and disappearing)

Reporters, please test the patch and report wheher it solves the bug for you.

Git commit 92fe9ac171b9920ba65adf244c7dbe23d694d209 by Matěj Laitl.
Committed on 11/06/2012 at 17:00.
Pushed by laitl into branch 'master'.

MediaDeviceCache: remove polling, solid events should suffice

This fixes a bug where Amarok (very probably needlessly) polls solid
for all devices every single second (!!!) just to detect whether some
unmounted paths become mounted or vice versa. This should not be needed
at all, solid should notify us about everything.

Let's hope this doesn't cause subtle bugs, but several people already
tested it with success [thanks, Sam]. (probably none of them with older
kdelibs though)
FIXED-IN: 2.7
REVIEW: 105221

M  +0    -43   src/MediaDeviceCache.cpp
M  +0    -2    src/MediaDeviceCache.h

http://commits.kde.org/amarok/92fe9ac171b9920ba65adf244c7dbe23d694d209

Hi Matěj,

Sorry, I misunderstood comment #13. I thougth you would come with another patch, because "it is rather a risky one ...". I've patched version 2.5.0-9.fc17.x86_64 and can confirm that your commit stops the spamming ... and Amarok still works :-) My local collection is still there. I've no mtp devices, very rarely use CD's, or other removeble devices. If you wish I can try to create such testcases.

For now I'm very happy with Amarok, Thanks.

Btw. What does mean: "(...) I won't push it for 2.6 (...)"? Will you come with another better solution?

Martin Kho

(In reply to comment #16)
> Hi Matěj,
> 
> Sorry, I misunderstood comment #13. I thougth you would come with another
> patch, because "it is rather a risky one ...". I've patched version
> 2.5.0-9.fc17.x86_64 and can confirm that your commit stops the spamming ...
> and Amarok still works :-) My local collection is still there. I've no mtp
> devices, very rarely use CD's, or other removeble devices. If you wish I can
> try to create such testcases.
> 
> For now I'm very happy with Amarok, Thanks.
> 
> Btw. What does mean: "(...) I won't push it for 2.6 (...)"? Will you come
> with another better solution?

...because it is a very risky one, so we are not pushing risky stuff without extensive testing when we are only days away from a release.  Extensive testing needs more than a few days as this patch can break all sort of things and use cases.

However, I had the courage and commited the fix, as you can see in comment #15. Please test current Amarok git extensively to check this bug vanishes _and_ that "dynamic collection" feature works for smb, nfs, cifs mount-points.

(In reply to comment #13)
> There's now a patch at https://git.reviewboard.kde.org/r/105221/ that
> removes the polling. It is rather a risky one so I won't push it for 2.6,
> but please test it nontheless. Specifically, it may have some side-effects
> on detection of media devices (only MTP and CDs) and "dynamic collection"
> feature. (automatic detection of Local Collection folders on removable media
> & network filesystems appearing and disappearing)

There was also https://git.reviewboard.kde.org/r/104878/ which you could have simply accepted ... Its in openSUSE packages since over 3 months ...

(In reply to comment #19)
> There was also https://git.reviewboard.kde.org/r/104878/ which you could
> have simply accepted ... Its in openSUSE packages since over 3 months ...

Oh yes and sorry, I've completely forgot about your patch and duplicated your work. :-( I think the bugzilla integration for reviewboard should be better - filling bug number in reviewboard should add note the bug IMO.

Until then, please add notes to the bugs in addition to linking bugs in rb so that we have 2-way link. Sorry for the inconvenience.

You speak about a solid patch that went into kdelibs 4.8.4. Could you please point it out so that we can mention it in the release notes?

Hi Matěj,

Does your last post imply that you'll revert the Amarok patches? Do I still need to test them?

Thanks,

Martin Kho

FWIW. I've a system running kdelibs-4.8.4. - kdelibs-4.8.4-5.fc17.x86_64 - and an unpatched Amarok version - amarok-2.5.0-9.fc17.x86_64, but still see udev/udisk daemon spamming. Not sure if the solid patch is already in the Fedora version, though.

(In reply to comment #20)
> You speak about a solid patch that went into kdelibs 4.8.4. Could you please
> point it out so that we can mention it in the release notes?

Git commit b16cfec44104ded4a8959af4e790fe2f7d6d2745 by Mario Bensi.
Committed on 28/02/2012 at 16:22.
Pushed by bensi into branch 'KDE/4.8'.

Fix for mtab monitoring on Linux Add a QSocketNotifier pointing to the mtab fd.

REVIEW: 103954
Related: bug 293914

M +15 -1 solid/solid/backends/fstab/fstabwatcher.cpp
M +4 -0 solid/solid/backends/fstab/fstabwatcher.h

http://commits.kde.org/kdelibs/b16cfec44104ded4a8959af4e790fe2f7d6d2745

(In reply to comment #21)
> Hi Matěj,
> 
> Does your last post imply that you'll revert the Amarok patches?

No, at least not if someone doesn't report some horrible behaviour.

> Do I still need to test them?

Testing is always wanted, especially short before the release.

> FWIW. I've a system running kdelibs-4.8.4. - kdelibs-4.8.4-5.fc17.x86_64 -
> and an unpatched Amarok version - amarok-2.5.0-9.fc17.x86_64, but still see
> udev/udisk daemon spamming. Not sure if the solid patch is already in the
> Fedora version, though.

Almost for sure not. The patch is not even in the Amarok 2.6 beta, it is only in current trunk.

Hi Matěj,

Okay, I'll keep testing. I'm not sure we were talking about the same patch. I meant the solid patch which was commited by Stefan. You pointed at your patch in your latest comment? 

Martin Kho

Hi,

I've tested the patch for more than a week and haven't seen any issues. Tested:
1. cifs-mount (windows2000 on a very old laptop) (mount/unmount/mount)
2. fusefs/javafs, mounted at login time.

... and no dbus/udisks wake ups :-)

Martin Kho