Bug 406810 - Dolphin and Konqueror consume a lot of CPU when Plasma Vault or encfs directory is open for a while
Summary: Dolphin and Konqueror consume a lot of CPU when Plasma Vault or encfs directo...
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.68.0
Platform: Ubuntu Linux
: HI normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
: 421042 436699 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-04-23 13:31 UTC by Thomas Pfeiffer
Modified: 2021-05-06 18:48 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
CPU-flags compared between i7-3930K, i5-4200U and Virtualbox VM on i5-4200U as announced in comment 29 (16.43 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-08-19 19:22 UTC, Henning
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Pfeiffer 2019-04-23 13:31:44 UTC
SUMMARY
When I open a Vault in Dolphin and leave it open for a while, often it eventually starts consuming a lot of CPU (21 - 22% overall on a 4-core) without me doing anything with it.
It never does that outside of Vaults.

STEPS TO REPRODUCE
1. Open a Vault in Dolphin
2. Open a file in the Vault
3. Leave Dolphin open

OBSERVED RESULT
Eventually DOplhin can start consuming a lot of CPU

EXPECTED RESULT
Dolphin doesn't consume CPU while user does nothing

SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.15
KDE Plasma Version: 5.15.4
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.0
Kernel Version: 4.15.0-47-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 7,5 GiB of RAM

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2019-04-23 15:34:25 UTC
Yes, I have seen this as well. It's very reproducible.
Comment 2 Ivan Čukić 2019-04-29 05:36:25 UTC
Ineresting.

What happens if it is a manually created cryfs/encfs drive?
Comment 3 Johannes 2019-04-30 11:53:30 UTC
I can confirm the bug for a manually created EncFS directory.
Comment 4 Nate Graham 2019-04-30 11:55:15 UTC
In that case, seems Dolphinny rather than Vaulty.
Comment 5 Johannes 2019-05-01 23:00:17 UTC
I temporarily switched to Konquerer and it shows the same behavior. What do both file managers have in common?
Comment 6 Christoph Feck 2019-05-21 20:51:12 UTC
Konqueror uses Dolphin for the file management views.
Comment 7 Johannes 2019-05-21 20:57:02 UTC
that means it's a Dolphin bug, right?
Comment 8 Nate Graham 2019-05-21 21:08:37 UTC
Yep.
Comment 9 Johannes 2019-07-13 23:30:31 UTC
It seems this bug is not limited to encrypted folders anymore. When I open my (unencrypted) home directory, Dolphin immediately starts consuming 100% of one CPU. The only error I see upon running it from command line is 'kf5.kio.core: "Could not enter folder tags:/."'
Comment 10 Johannes 2019-07-13 23:40:57 UTC
Another interesting observation (the encrypted EncFS folder is mounted to a folder in the home directory):

First opening the home folder in Dolphin, then mounting the EncFS folder => everything OK.

First mounting the EncFS folder, then opening the home folder in Dolphin => 100% load.
Comment 11 Nate Graham 2019-07-16 14:31:52 UTC
(In reply to Johannes from comment #9)
> It seems this bug is not limited to encrypted folders anymore. When I open
> my (unencrypted) home directory, Dolphin immediately starts consuming 100%
> of one CPU. The only error I see upon running it from command line is
> 'kf5.kio.core: "Could not enter folder tags:/."'
That's an unrelated issue, and a new bug should be filed for it.
Comment 12 Johannes 2019-07-16 15:08:49 UTC
How's that unrelated? If an encrypted subfolder is mounted, Dolphin behaves as showing that folder, if it's not mounted, everything's fine.
Comment 13 Johannes 2019-07-28 13:52:31 UTC
I now even saw a Dolphin process with 100% CPU consumption without having any instance of Dolphin running.
Comment 14 Adrián Chaves (Gallaecio) 2019-08-16 06:50:20 UTC
Which version of cryfs are you using? Does it happen with cryfs 0.9.11?
Comment 15 Johannes 2019-08-16 10:17:16 UTC
EncFS 1.9.5 here
Comment 16 Johannes 2019-08-21 09:44:24 UTC
anyone has an idea how to fix/control that bug?
Comment 17 Adrián Chaves (Gallaecio) 2019-08-21 09:51:22 UTC
A workaround may be be to switch to a different backend, such as cryfs.
Comment 18 Enrico Ronconi 2019-10-08 09:19:47 UTC
For me the problem exists only if "Preview" are enabled for current directory.
Thus possible workaround is disabling preview for affected directories.
Comment 19 Thomas Pfeiffer 2019-11-01 13:21:41 UTC
(In reply to Adrián Chaves (Gallaecio) from comment #14)
> Which version of cryfs are you using? Does it happen with cryfs 0.9.11?

Ich have cryfs 0.9.9.
Is there an easy way to get 0.9.11 on neon to test it?
Comment 20 Thomas Pfeiffer 2019-11-03 17:44:35 UTC
(In reply to Enrico Ronconi from comment #18)
> For me the problem exists only if "Preview" are enabled for current
> directory.
> Thus possible workaround is disabling preview for affected directories.

Same here, it seems like the preview is the problem.
Comment 21 drokergeek 2020-02-12 18:33:35 UTC
I can say that at the beggining when vault was introduced, no lag when browsing a folder of the vault (i use cryfs), and i could have thumbnails and previews without any issue, and since some time ago (some months) i can't even have previews or thumbnails in dolphin (gwenview does create thumbnails) and browsing, even with preview disabled, is very laggy
Comment 22 Nate Graham 2020-05-05 16:51:56 UTC
*** Bug 421042 has been marked as a duplicate of this bug. ***
Comment 23 Henning 2020-06-23 19:59:38 UTC
Same here:
- encfs 1.9.5 mounted by command line or KencFS (same result)
- OS: Kubuntu 20.04 64bit
- Kernel 5.4.0-37-generic
- Plasma: 5.18.5
- KDE Framework: 5.86.0
- Qt: 5.12.8

Different steps to reproduce:
- Open a file from encrypted directory with Dolphin
- Save that file with the application it was opened with
=> CPU-load of one core goes to 100% and stays there until Dolphin is closed

- closing the file or the application doesn't help
- opening the file directly with the application makes no trouble

I'm using encfs and Kubuntu since 12.04 (only the LTS-Versions; encfs might have come with 14.04) and I never observed this problem. 20.04 was a fresh install and no KDE-settings have been copied from the 18.04-homedir. All previews in Dolphin are disabled (they just confuse me, I need my filetype symbols).
Comment 24 Nate Graham 2020-06-23 21:00:42 UTC
FWIW I'm unable to reproduce this with the git master version of everything KDE. But it's possible that an update to encfs itself fixed this. 

Can anyone on Arch or openSUSE Tumbleweed with latest KDE stuff (built from source or using unstable repos) confirm?
Comment 25 Henning 2020-07-03 17:16:37 UTC
What I tried since the last post:
I found out that on an identically installation (not a clone) on my notebook with a copy of the encfs-folders the problem did not exist.
On the PC with the dolphin-encfs-problem ...
- I created a new user: no solution
- I created a new encfs-folder: no solution
- I removed all non-standard mount options from the drives: no solution
- I copied the complete system from the notebook to the PC (and made it boot again): no solution!!!
- I installed SpaceFM (small, few dependencies, but I like dolphin much more): anything working correct
Additionally I found out ...
- that the problem only exists with programs  creating tmp/bak/swp-files like kate/kwrite and libreoffice
- that the cpu-load normalizes when changing to another directory, but it goes back to 100% on one core when one goes back to the directory of the files
- that the cpu-load normalizes when completely deleting the file
- that the cpu-load normalizes after putting the file to the waste bin and restoring it

The problem is reproducible with the live usb drive with Kubuntu 20.04.0. Trying live usb drives with "neon-user-20200702-1117" and "openSUSE-Leap-15.2-KDE-Live-x86_64-Build31.105-Media" act as expected. This means that it is a Kubuntu 20.04.0 problem which appears only on some computers. Hence this are the data of my computers:
PC with the problem: i7-3930K, X79 Express chipset, 64 GB RAM, AMD RX580 GPU
Notebook: i5-4200U, ??? chipset, 12 GB RAM, integrated Intel GPU used, additional GeForce GT 750M not used but driver installed

Finally this probably means that I'm in the wrong forum as it is Kubuntu-specific. Sorry!
Comment 26 Nate Graham 2020-07-03 17:30:59 UTC
Thanks for the detailed investigation! That's very helpful.

I don't think it's Kubuntu-specific though; I was experiencing it in the past on openSUSE Tumbleweed, and I'm still using that OS but now it's gone for me.
Comment 27 jacob.becker 2020-08-18 02:55:16 UTC
I contacted Henning an during a testing session we discovered that the issue still kan be triggered wit an new Kubuntu 20.04.1 live-Session, if you have an older CPU in your system.

No special requirement and 100% reproducible on my lenovo x230 thinkpad wit Intel Core i7 3XXX CPU.

a) Start live-Session of Kubuntu
b) create a encfs (all the tools are already installed - no network connection neccessary)  
encfs /path/to/encrypted_folder /path/to/unecrypted_folder
(you can choose the paranoia settings) and set a password 

c) Open the unecrypted folder in dolphin an create a libre-office file.
d) leave the dolphin folder-view open an type some garbage in the file - the contend doesn't matter
e) Save the file in libre office
f) Dolphin now uses 100% CPU of a core

In Kubuntu 20.04.1 you can press F5 or change the folder in dolphin to another one to get thing back to normal.
I'm currently testing some VM environments with cpu-flags if i can recreate the same behavior on more modern CPUs.
Comment 28 jacob.becker 2020-08-19 00:47:41 UTC
I changed some of the bug-details so that they showing the vversion on wich the bug can be easily be repoduced. 

I tried some cpu-flags wit kvm on my tumbleweed machine.

While tumbleweed itself does not show teh bug due tuo newer qt and framwork versions, i can tell that a virtual machine based on kvm ist preatty sufficient to show the bug.

i tried EPYC-IBPB, Westmere, Westmere (without CPU flaw mitigations), Sandy Bridge and qemu64 as cpu settings and they all show the same behavior.

So nearly everybody should be able to witness this behavior.
I will try to test it on different real systems as well..
Comment 29 Henning 2020-08-19 19:19:38 UTC
Assuming that the Dolphin+EncFS-problem is a result of the CPU/CPU-flags in conjunction with the compiler/compiler-flags I also did some further investigations. Out of habit I used "Oracle VM Virtualbox" with host-extensions installed for USB support. (No guest-extensions installed by me; Virtualbox 6.1) The results:
i5-4200U host: Kubuntu 20.04.1 works fine with Dolphin+EncFS
VM on that i5-4200U host: Kubuntu 20.04.1 shows the Dolphin+EncFS-problem
i7-3930K host: Kubuntu 20.04.1 shows the Dolphin+EncFS-problem

Therefore I took a look at the CPU-flags by comparing the output of /proc/cpuinfo. If I can attach the LO-calc-file, I will do so. But from my point of view, these flags are the most interesting:
Flag only on the two systems where the problem appears (VM@4200U and 3930K): x2apic
Flags missing on the two systems where the problem appears but available on the working system (4200U): bmi1, bmi2, cpuid_fault, ept_ad, erms, f16c, fma, sdbg, smep, tsc_adjust.
There are a lot flags missing only in the VM and some others are missing on the 3930K only. Hence I listed all flags that are common on the systems where the Dolphin+EncFS-problem appears.

Since I don't really know much about CPU- or compiler-flags, I also played around with CPU-microcode and patches on the native 3930K. Booting without any microcode loaded to the CPU by Kubuntu does not solve the Dolphin+EncFS-problem just as adding "mitigations=off" to grub.

Does anyone have an old ISO-image of Neon with Plasma 5.18? Testing Dolphin+EncFS there inside a VM would be quite interesting!

P.S.: A Kubuntu 20.04.1-VM on the i5-4200U running Win10 as host OS also shows the Dolphin+EncFS-problem.
Comment 30 Henning 2020-08-19 19:22:30 UTC
Created attachment 131021 [details]
CPU-flags compared between i7-3930K, i5-4200U and Virtualbox VM on i5-4200U as announced in comment 29
Comment 31 Henning 2020-09-06 22:28:16 UTC
WORKAROUND FOUND

First, sorry for the confusion with processor flags and so on. My 'solution' is extremely easier but means that there is really a bug in Dolphin under Kubuntu 20.04.1.
Jacob proposed to create a new user on the installation on the notebook where the problem does not appear. Very good idea, because the problem appeared with the new user. Hence, everbody can reproduce the problem with any Kubuntu 20.04 and it is the standard when using EncFS with Dolphin.
I really compared the settings of Dolphin and the KDE settings and it took me a lot of time. More time was wasted comparing CPU flags and investigating VM behaviour. But since the problem appeared with the new user on the notebook, it had to be a setting. I would have searched there if I wasn't sure I had adjusted all settings correctly.
Finally the problem does not appear, when one disables the file preview in Dolphin. This setting is not in the menu settings > setup Dolphin but really easy to find in the menu view (or whatever it is callend in English; third menu when showing the menu bar, entry no. 8).
If you enable to see hidden files and the preview, Dolphin goes to 100% on one core as soon as you begin typing something into an existing textfile in Kate.
With only preview enabled, the problem appears when saving and disappears after updating the view - as discribed in the past.
Disabling the prewiew, anything works fine on the EncFS folder regardless of showing hidden files or not. Thus, I do not have a problem anymore, but I hope that the Kubuntu team will fix this bug. Perhaps this also helps Thomas.
The setting if the preview is disabled is stored in the hidden file ~/.local/share/dolphin/view_properties/global/.directory in the section [Dolphin] by the line PreviewsShown=false.

Thanks - Henning
Comment 32 Nate Graham 2021-05-06 18:48:35 UTC
*** Bug 436699 has been marked as a duplicate of this bug. ***