Date: Tue, 24 Oct 2000 15:32:01 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: ps@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vm_pageout_scan badness Message-ID: <200010242232.e9OMW1X21204@earth.backplane.com> References: <20001024112708.E28123@fw.wintelcom.net> <200010242010.e9OKAJK19739@earth.backplane.com> <20001024151414.P28123@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
:
:Perhaps if you detected how often the routine was being called you
:could slowly raise max_page_launder to compensate and lower it
:after some time without a shortage. Perhaps adding a quarter of
:'should_have_laundered' to maxlaunder for a short interval.
:....
: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.
We definitely don't want to increase max_page_launder too much... the
problem is that there is a relationship between it and the number of
simultanious async writes that can be queued in one go, and that can
interfere with normal I/O. But perhaps we should decouple it from the
I/O count and have it count clusters instead of pages. i.e. this line:
written = vm_pageout_clean(m);
if (vp)
vput(vp)
maxlaunder -= written;
Can turn into:
if (vm_pageout_clean(m))
--maxlaunder;
if (vp)
vput(vp);
In regards to speeding up paging, perhaps we can implement a heuristic
similar to what buf_daemon() does. We could wake the pageout daemon up
more often. I'll experiment with it a bit. We certainly have enough
statistical information to come up with something good.
-Matt
:-Alfred
:
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?200010242232.e9OMW1X21204>