Summary: | kde-frameworks/baloo-5.43.0 in Gnome session - runs with 99.99 % of IO bandwidth | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Juergen Rose
2018-02-15 20:55:37 UTC
>> I did not start any kde programm.
At this point I was wrong. Okular was running.
Now on the next system just after the login into gnome via lightdm (I started only one xterm and firefox) iotop shows 99.99% bandwidth for baloo_file_extractor: 4427 be/4 root 12.02 Ms 0.00 B/s 0.00 % 80.36 0.00 B2.7 -b /usr/lib/python-exec/python2.7/emerge -pvueDN system 6406 be/4 root 395.17 K/s 0.00 B/s 0.00 % 73.41 % diff --brief -r //usr/share/desktop-directories~t/Configurations///usr/share/desktop-directories 1952 be/3 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [jbd2/dm-4-8] 6599 be/4 rose 228.26 K/s 0.00 B/s 0.00 % 99.99 % firefox [Cache2 I/O] 6853 idle rose 11.71 M/s 0.00 B/s 0.00 % 97.73 % baloo_file_extractor 4427 be/4 root 45.65 K/s 0.00 B/s 0.00 % 69.90 % python2.7 -b /usr/lib/python-exec/python2.7/emerge -pvueDN system 6560 be/4 root 38.04 K/s 0.00 B/s 0.00 % 65.70 % python2.7 -b /usr/lib/python-exec/python2.7/emerge -pvueDN system 4503 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.38 % [kworker/3:0] 4351 be/4 rose 0.00 B/s 0.00 B/s 0.00 % 0.06 % gnome-shell I'm not sure what we are supposed to do here... do you think the time is well spent on figuring out why it runs in your Gnome session at all, or do you simply not want to have to deal with baloo anyway (USE=-semantic-desktop is all you need) (In reply to Andreas Sturmlechner from comment #3) > I'm not sure what we are supposed to do here... do you think the time is > well spent on figuring out why it runs in your Gnome session at all, or do > you simply not want to have to deal with baloo anyway (USE=-semantic-desktop > is all you need) My systems seems to be rather slow, I try to find the reason. I found that baloo_file_extractor is running using 4-5GB of memeory and 99 % of IO-Bandwith. So I am wondering whether the baloo_file_extractor is responsible for the slowness. I do not see at least that baloo_file_extractor is using so much memory at other systems. Then I wondering whether I can disable baloo and kdeinit5, if I running a Gnome desktop. I wonder what packages you have pulling in baloo in Gnome? (equery d kde-frameworks/baloo) baloo is seriously broken with respect to io consumption. Broken like so many of the semantic desktop crap tools in kde, current and past (nepomuk...). This is a known state for quite some time (for years). For me I'm fed up with tools that cause a load of 5 when they're supposed to be imperceptible. Googling "baloo io consumption" reveals many reports of this kind of behaviour in other distros or bugs.kde.org. The problem pops up again and again -- most people conclude to turn it off and that's what I recommend wholeheartedly. Just kill it, "balooctl disable" sometimes keeps the process running. There is another solution: http://www.freehackers.org/thomas/2014/05/03/fix-baloo-on-kde-using-the-same-trick-as-onced-used-with-nepomuk/ Sorry for the rant. Your rant is offtopic and the link completely useless considering our very useful USE="-semantic-desktop" feature on Gentoo. I know and the link was neither meant to be a serious recommendation nor am I blaming the Gentoo kde team. It would just be good to have a different solution to tame baloo then to turn the whole thing off. Semantic desktop, in principle, is an important feature. (In reply to Michael Palimaka (kensington) from comment #5) > I wonder what packages you have pulling in baloo in Gnome? (equery d > kde-frameworks/baloo) root@lynxold:/root(23)# equery d kde-frameworks/baloo * These packages depend on kde-frameworks/baloo: kde-apps/baloo-widgets-17.12.2 (>=kde-frameworks/baloo-5.40.0:5) kde-apps/dolphin-17.12.2 (semantic-desktop ? >=kde-frameworks/baloo-5.40.0:5) kde-apps/gwenview-17.12.2 (semantic-desktop ? >=kde-frameworks/baloo-5.40.0:5) root@lynxold:/root(24)# emerge -pv1 baloo-widgets dolphin gwenview These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] kde-apps/baloo-widgets-17.12.2:5::gentoo USE="-debug {-test}" 0 KiB [ebuild R ] kde-apps/dolphin-17.12.2:5::gentoo USE="handbook semantic-desktop -debug {-test} -thumbnail" 0 KiB [ebuild R ] kde-apps/gwenview-17.12.2:5::gentoo USE="X fits handbook raw semantic-desktop -debug -kipi {-test}" 0 KiB Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB root@lynxold:/root(25)# grep semantic-desktop /etc/make.conf semantic-desktop (In reply to Michael Palimaka (kensington) from comment #5) > I wonder what packages you have pulling in baloo in Gnome? (equery d > kde-frameworks/baloo) Digikam seems to depend on semantic-desktop too: root@lynxold:/root(29)# equery h semantic-desktop * Searching for USE flag semantic-desktop ... [IP-] [ ] kde-apps/dolphin-17.12.2:5 [IP-] [ ] kde-apps/gwenview-17.12.2:5 [IP-] [ ] media-gfx/digikam-5.7.0-r3:5 (In reply to Andreas Sturmlechner from comment #3) > I'm not sure what we are supposed to do here... do you think the time is > well spent on figuring out why it runs in your Gnome session at all, or do > you simply not want to have to deal with baloo anyway (USE=-semantic-desktop > is all you need) I removed semantic-desktop from /etc/make.conf, reemerged dolphin, gwenview and digikam, depcleaned baloo-widgets and baloo and killed the still running baloo_file_extractor and baloo_file. And some seconds later the disk activity LED does not anymore show permanent disk activity. Thanks for the hint. Since we are not going to solve the resource consumption in here, which as far as upstream concerned is notabug, and the offending package has been removed since, there's probably nothing to do here anymore. *** Bug 653604 has been marked as a duplicate of this bug. *** |