Date: Mon, 13 Nov 1995 14:12:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: dufault@hda.com, terry@lambert.org, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511132112.OAA18081@phaeton.artisoft.com> In-Reply-To: <199511132054.HAA06582@godzilla.zeta.org.au> from "Bruce Evans" at Nov 14, 95 07:54:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >I have seen pauses on the order of a second or two on a SCSI system
> >with PCI + NCR controller.
>
> Another one:
>
> char buf[1024*1024]; main() { write(1, x, sizeof x); }
>
> When fd 1 is connected to /dev/ttyv3 (syscons), the write() syscall
> takes 6.71 seconds to complete, during which time no other processes can
> run. Writing 16MB would take 100 seconds. (To kill the process, type
> ^S^C. ^C alone doesn't work because signal handling is delayed until
> the process goes to sleep or returns from the syscall.) No disks are
> involved.
OK, we can rule out the console here. I am running the machine headless
using an Xterm from another box.
> System: 486DX2/66 VLB ET4000/W32i (video write bandwidth = 25MB/sec;
> efficiency = 0.25% :-().
>
> When fd 1 is connected to a disk file and the array size is increased to
> 32MB, the i/o takes about 11 seconds to complete, during which time the
> system seems to be frozen. `iozone 32 65536' reports a write time of
> about 8 seconds. The vm system is doing a good job of handling about
> 20MB of the array that doesn't fit in memory.
I thought that there was a working set quota on either a per process
or a per vnode basis at one time? The per vnode working set is easy
to implement; change the LRU insertion order for pages the are forced
out by the working set to cause them to be reused first. This will
result in a bit of thrashing for the pages involved, but the rest of the
system will operate efficiently.
A per process working set quota will fix the problem more cleanly in
theory, even if the code is more complex.
A good "half measure" soloution is to establish a per vnode high water
mark and track the cache pages on a per vnode basis. The second half
of this is to only enforce the watermark if the amount of free VM is
below a certain amount -- a low watermark.
This interaction should cause a balanced hysteresis to keep the quota
from adversly affecting process timing by causing undue cache thrashing
for the oitherwise cache-trashing process until a high system load is
reached, at which point there will be a minimum free reserve on reuse
(the sleeps are waiting for pages at this point).
This is exactly the problem that UnixWare has with ld mmap'ing everything
it is linking together and (effectively) forcing everything else out of
the cache. They don't have a quota. I hacked the code on UnixWare once
as a proof of concept, but you wouldn't believe how hard it is to get
code into the UnixWare source tree.
> All these problems are essentially the same: i/o's are done synchronously
> if possible and large synchronous i/o's cause long freezes.
8-(. Maybe better to split them up, then, favoring response time over
absolute efficiency?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511132112.OAA18081>