Date: Tue, 24 Oct 2000 15:50:35 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: ps@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: vm_pageout_scan badness Message-ID: <20001024155035.Q28123@fw.wintelcom.net> In-Reply-To: <200010242232.e9OMW1X21204@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Oct 24, 2000 at 03:32:01PM -0700 References: <20001024112708.E28123@fw.wintelcom.net> <200010242010.e9OKAJK19739@earth.backplane.com> <20001024151414.P28123@fw.wintelcom.net> <200010242232.e9OMW1X21204@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [001024 15:32] wrote: > > :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: Ok, now I feel pretty lost, how is there a relationship between max_page_launder and async writes? If increasing max_page_launder increases the amount of async writes, isn't that a good thing? > > 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. That looks like it would help by ignoring the clustered data which probably got written out pretty quickly and reducing the negative cost/gain to a single page. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20001024155035.Q28123>