Bug 60138

Summary:	Kmail spinning and eating CPU waiting for gnupg
Product:	[Unmaintained] kmail	Reporter:	gallir
Component:	encryption	Assignee:	kdepim bugs <pim-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	benoit.mortier, bjoern, bss, david, esigra, greg_g
Priority:	NOR
Version First Reported In:	1.5.2
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description gallir 2003-06-20 18:33:29 UTC

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

Comment 1 Ingo Klöcker 2003-06-22 21:52:33 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.

Comment 2 Michael Pyne 2003-07-17 03:53:34 UTC

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.

Comment 3 Benoit Mortier 2003-08-21 13:47:50 UTC

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

Comment 4 Michael Pyne 2003-08-27 07:06:03 UTC

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. :(

Comment 5 gallir 2004-01-24 21:41:19 UTC

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.

Comment 6 Paul Walker 2004-07-31 13:02:37 UTC

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."

Comment 7 David Faure 2004-08-10 15:15:58 UTC

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.

Comment 8 Fernando Vilas 2008-11-09 15:19:50 UTC

In KDE 4.1.2, this no longer appears to busy-wait.

Comment 9 Björn Ruberg 2009-12-20 14:46:58 UTC

So I consider this as fixed