Re: Very bad interactive response, and awful amount of system time

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sat, 6 Jun 2009 17:20:11 +0200
Rhialto <rhialto%falu.nl@localhost> wrote:

> I noted that the interactive response of other tasks suffered
> progressively more and more under the load. At one point, it had gotten
> so bad that getting an echo in an xterm took seconds! (Of course,
> complex programs like Firefox suffered even worse)

I used netbsd-5 rather extensively to build software (rebuilt all my
packages repository under it lately) but have not noticed this bad
interactive performance, unless RAM was low enough to cause say, ff3 to
be swapped out.  I also don't have a high system time, although it's a
bit higher than on netbsd-4 (mostly ioflush takes more CPU time than
previously, but also nfsio threads).

I did notice some C++ builds being stuck in ld(1) for a while taking
all CPU time it could, which seemed new to me (I assume GNU ld uses a
very bad algorithm in a critical code path, but did not check), but
this doesn't seem kernel related.

However, a noticeable difference is that if a process is reniced, even
say to 2, it remains stuck for a while if another process at priority
0 uses a lot of CPU, and this may be a related issue.  I'd expect the
reniced process to be allowed less cycles, but not to be totally
starved when at priority +2 (perhaps with +10 it'd make sense).

I'll also try the diff Mindaugas proposed tomorrow to see if it
helps in this scenario.

Thanks,
-- 
Matt