Summary: | Kmail spinning and eating CPU waiting for gnupg | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | gallir |
Component: | encryption | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | benoit.mortier, bjoern, bss, david, esigra, greg_g |
Priority: | NOR | ||
Version: | 1.5.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
gallir
2003-06-20 18:33:29 UTC
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 |