Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Oct 2000 10:12:53 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        bright@wintelcom.net (Alfred Perlstein)
Cc:        dillon@earth.backplane.com (Matt Dillon), ps@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   Re: vm_pageout_scan badness
Message-ID:  <200010251012.DAA19288@usr02.primenet.com>
In-Reply-To: <20001024151414.P28123@fw.wintelcom.net> from "Alfred Perlstein" at Oct 24, 2000 03:14:14 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> > I'll take a crack at implementing the openbsd (or was it netbsd?) partial
> > fsync() code as well, to prevent the update daemon from locking up large
> > files that have lots of dirty pages for long periods of time.
> 
> Making the partial fsync would help some people but probably not
> these folks.

I think this would be better handled as a per file working set
quota, which could not be exceeded, unless changed by root.

Consider that a file with a huge number of pages outstanding
should probably be stealing pages from its own LRU list, and
not the system, to satisfy new requests.  This is particularly
true of files that are demanding resources on a resource-bound
system.


> The people getting hit by this are Yahoo! boxes, they have giant areas
> of NOSYNC mmap'd data, the issue is that for them the first scan through
> the loop always sees dirty data that needs to be written out.  I think
> they also need a _lot_ more than 32 pages cleaned per pass because all
> of thier pages need laundering.

First principles?

What are they doing, such that this situation arises in the
first place?  Having a clue to the problem they are trying to
resolve, which causes this problem as a side effect, would
both help to clarify if there were a better soloution for them,
as well as what FreeBSD should potentially act like they were
asking for instead, when/if the situation arose.


> It might be wise to switch to a 'launder mode' if this sort of
> usage pattern is detected and figure some better figure to use than
> 32, I was hoping you'd have some suggestions for a heuristic to
> detect this along the lines of what you have implemented in bufdaemon.

This is kind of evil.  You could do low and high watermarking,
as you suggest, but without any idea of the queue retention
time to expect, and how bursty the situation is, there's no
way to pick an appropriate algorithm.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010251012.DAA19288>