> > >From what you've said, though, you have execmin set to 5, which means
> > on a 128 meg machine like yours you'll be miserable. Set it up to 20
> > and let us know how things feel.
>
> It's not a tuning problem. I looked at this as well, and couldn't find a
> tuning that makes it behaves properly. Running X, while doing a cp

tried many settings. both huge execmin/max, small filemin/max

no real difference. problem is not there

> (a dd if=/dev/zero of=file bs=64k is enouth, in fact), the X server is

tried this a while before (added count=2048 so it took only while).
resulted in complete unusability for a while.

> stuck. A top running remotely (text mode is fine, the problem is really with
> the X server) shows that X is blocked on biowait. No need for memory-ungry
> apps, just X with a xterm is enouth.

yes. problem persist for me even with x+xterm and nothing more.

> running top in a xterm). It starts as soon as the write start, and stops
> as soon as the write stops. I don't know yet what cause this (if it's
> activity to swap partition, or if it's some file that the X system has to read
> for each event, or such).

this looks like general error somewhere.

>
> Anyway, I really think the rigth way to fix this is not to bend the VM
> system to handle X especially, but to different I/O priorities, based
> on process I/O behavior. This would solve a whole class of problems.

and it must be solved before even thinking of making release candidate.
it's not small problem, it's performance killer which makes NetBSD in
real-world cases behaving like windows 98 (where copying large files swaps
out everything).


--------------------------------
Where do you think you go today?