Version: 1.5.2 (using KDE 3.1.2) Installed from: (testing/unstable) Compiler: gcc version 3.3 (Debian) OS: Linux (i686) release 2.4.21-ck2 While we were playing with COn Kolives with the Linux scheduler, we realised that when a signed or encrypted message is selected, kmail does spin waiting for (I guess) pgp/gpg to start. If some kernel scheduler parameters are changed (in our case: child_penalty), kmail eats 100% of CPU for several seconds, up to 30 in our extreme case I _think_ it's more related to libkdenetwork which creates the pipe and do the polling. Could be sched_yield used at least to save some ticks? Thanks
Subject: Re: New: Kmail spinning and eating CPU waiting for gnupg Thanks for the bug report. I just wanted to let you know that we plan to make the usage of gpg asynchron. I guess this will also fix the problem you encountered.
If it helps, the next linux kernel (2.6.0-test1) gives me the same problem, which didn't exist before in mainline 2.4.21. It takes anywhere from a few seconds to 15 seconds for encrypted emails or emails which I'm encrypting to finish. Using gpg from the command line gives no problems.
i got the same problem using gnupg 1.2.2 an kmail from kde 3.1.3 gnupg got 80% of cpu and kmail 35% and it could take up to 2 min to get pinetry dialog this problem didn't happen with gnupg 1.2.1 from the command line i got no problem with gnupg 1.2.2 os debian woody 3.0 kmail = 3.1.3 libgcrypt1 = 1.1.12 libksba0 = 0.4.7 gpgsm = 0.9.4 libgpgme6 = 0.3.15 cryptplug = 0.3.15 pinentry-qt = 0.6.9 gnupg = 1.2.1
According to Con Kolivas's write-up of the problems faced by the new schedulers in 2.6 (http://kerneltrap.org/node/view/780), KMail is suffering from 'priority inversion', which is where it spawns gpg, and then busy-waits for the result. The problem is that KMail gets scheduled much more often than gpg since it is interactive, and gpg is a CPU hog according to the new scheduler. Thus, KMail is allowed to busy-wait all the CPU time away from gpg until they busy waiting affects KMail's own scheduling priority. It seems that the solution is to find a way to wait for gpg's result without using a busy-wait loop or the like. I'm not sure if this means the problem is in KMail or kdenetwork. :(
In KDE 3.2 the problems is more obvious with kernel 2.6.1 (that's to say, is still not asynchronous as promised ;-). I think a sched_yield(); in the busy wait will help a lot.
Whether the sched_yield helps depends on how the scheduler defines highest priority in this case. If it considers that KMail is a higher priority, then yielding won't help with the priority inversion. From the sched_yield man page: "Note: If the current process is the only process in the highest priority list at that time, this process will continue to run after a call to sched_yield."
gpgme makes the gnupg stuff asynchronous in 3.3, i.e. kmail doesn't block anymore. But that's currently only used for signing/encrypting, not yet for decrypting/checking signatures - khz is supposed to work on that.
In KDE 4.1.2, this no longer appears to busy-wait.
So I consider this as fixed