: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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message