freebsd stable - Apr 2006 - 6.1 responsiveness under heavy (cpu?) load + thread monitoring

Hello,

I have a RELENG_6/AMD64 with an AMD64X2 cpu, 1GB of memory, 512MB swap.
I remarked that when I run 2 simulation program [1], sometimes, one of them
run one or several of its threads [2] very slowly, but sometimes, it doesn't
occur.

I remarked that is doesn't depend on SMP/UP, ULE/4BSD, i386/AMD64.

It seems to occur also with the kernel stress test under the same conditions
(all of them).
In this case, the mouse is blocked, etc. I tested different kernels, and
recorded the output of sysctl vm [3].

I increased vm.swap_async_max but this doesn't change the deal /a priori/.

All that didn't occur with a Sempron64. All was slower but the mouse
didn't
blocked etc. This was a time ago, I may be wrong.

It seems to be an architecture problem (??).
I can give more quantitative data, but I need help to focus the tests...

Mathieu

[1] http://ising.podzone.org/src/ising_lps_0.4.tar.bz2
[2] void *interface(void *arg) can be very slow, void *system_trace(void *arg)
 can exit during a very long time (terminated ? detached: it should).
[3] http://ising.podzone.org/vm/vm_amd64.tar.bz2 and others in this directory

PS: does FreeBSD allow monitoring threads of a program in real time ?
I didn't find anything for freebsd.

> Date: Sat, 1 Apr 2006 16:34:25 +0200
> From: Mathieu Prevot <freebsd-stable@club-internet.fr>
> Sender: owner-freebsd-stable@freebsd.org
> 
> Hello,
> 
> I have a RELENG_6/AMD64 with an AMD64X2 cpu, 1GB of memory, 512MB swap.
> I remarked that when I run 2 simulation program [1], sometimes, one of them
> run one or several of its threads [2] very slowly, but sometimes, it
doesn't
> occur.
> 
> I remarked that is doesn't depend on SMP/UP, ULE/4BSD, i386/AMD64.
> 
> It seems to occur also with the kernel stress test under the same
conditions
> (all of them).
> In this case, the mouse is blocked, etc. I tested different kernels, and
> recorded the output of sysctl vm [3].
> 
> I increased vm.swap_async_max but this doesn't change the deal /a
priori/.
> 
> All that didn't occur with a Sempron64. All was slower but the mouse
didn't
> blocked etc. This was a time ago, I may be wrong.
> 
> It seems to be an architecture problem (??).
> I can give more quantitative data, but I need help to focus the tests...
> 
> Mathieu
> 
> [1] http://ising.podzone.org/src/ising_lps_0.4.tar.bz2
> [2] void *interface(void *arg) can be very slow, void *system_trace(void
*arg)
>  can exit during a very long time (terminated ? detached: it should).
> [3] http://ising.podzone.org/vm/vm_amd64.tar.bz2 and others in this
directory
Mathieu,

Any chance your system was running tight on memory? How much does it
have and is the system using any swap space?

I suspect that something is not working well in V5 or V6 with writing
to/reading from swap. I have reported a similar problem and Kris
K. asked me to try adjusting vm.swap_async_max, but the system has been
replaced and I ave been having trouble getting a systems set up to
test. (Disk died.) I hope to try Kris's suggestion next week, but your
report makes this seem less likely.

I can say that I don't see this on my new system which increased memory
from 256MB to 1GB. Needless to say, it seldom has to use the swap file
and I must agree that it seems tied to threaded processes.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634