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>