On Thu, Apr 08, 2004 at 01:42:35AM -0700, Erik E. Fair wrote:
> I've spent the last 36 hours fighting limitations in NetBSD 1.6.2. The
> problems I've had indicate deeper trouble in NetBSD's design that we need to
> deal with.

Okay, but I'm not at all sure that the trouble is what you think it is.

> Examination of the system state with top and systat indicated that I'd run
> out of RAM for caching file data, and none was being released. UVM trouble?
> I aborted the dump, and RAM utilization returned to normal. This was some kind
> of interruptible deadlock. Very nasty: the implication is that a full dump of
> an FS that big is impossible on a system with only 512MB of RAM.

No.  You draw a demonstrably incorrect inference; I dump far larger
filesystems on machines with less memory; and so did you, in your
second attempt.

I am concerned, however, that pages belonging to the file cache are not
reliably released upon demand from other in-kernel consumers.  I think
that we may need to adjust how scanning for pages is triggered, among
other things; this problem becomes more obvious with the new metadata
cache, but I think it's existed all along and caused this sort of issue
especially in the "must allocate to write" case -- for example, for MFS
and cgd (which Roland recently fixed) and RAIDframe and the softdep
code and possibly for ccd.

Thor