Subject: Re: NetBSD 1.6 Release Schedule
To: Wojciech Puchar <wojtek@chylonia.3miasto.net>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: port-i386
Date: 06/20/2002 00:06:20
On Wed, Jun 19, 2002 at 11:51:57PM +0200, Wojciech Puchar wrote:
> > On Wed, Jun 19, 2002 at 03:50:58PM -0400, Perry E. Metzger wrote:
> > > UBC seems to be working fine. What do you think is wrong with it? Or
> > > is this your claim that the max/min memory usage sysctls aren't working?
> >
> > Thew issue when you copy a large file to the same disk as the system disk,
> > the system becomes ususable. It's not a problem with UBC per se, it
> > the "IO priority" problem I talked about a bit on tech-kern (the I/O
> > queue gets filled with writes, and another, small I/O request requires
> > seconds to get serviced).
> > This is not a problem with UBC per se. I've been fighting with this problem
> > on 1.5.2 mail servers (working around by limiting the write rate in
> > userland daemons). It's possible that UBC made it worse, though.
> >
> 
> it made it MUUUCH worse. copying large file under 1.5.2 made no noticable
> slowdown of programs like navigator. with 1.6BETA2 even xterm is unusable.

No, trust me this happens with 1.5.2 too. I've got to hack pop3 and imap
daemons to make it acceptable.

> 
> 
> the problem is that UBC does total wipeout of programs code and data. it's
> just overagressive. yes write flooding make things worse, but real problem
> is that apps need to reread swapped out/deallocated pages.

No, the root problem is that a single, small I/O can need several seconds to
complete because some other fills in the I/O queue.
Of course you can change the VM so that no program code or data will
never be paged out. When you move the mouse you won't notice the problem.
If you try to start a new program you run in the problem again (this is exactly
the problem I had on my 1.5.2 server: running progs are fine as long as they're
not swapped, but typing a command in a xterm is extremely slow).

You're just trying to solve the wrong problem.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--