Date: Tue, 24 Oct 2000 13:10:19 -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: <200010242010.e9OKAJK19739@earth.backplane.com> References: <20001024112708.E28123@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ouch. The original VM code assumed that pages would not often be
ripped out from under the pageadaemon, so it felt free to restart
whenever. I think you are absolutely correct in regards to the
clustering code causing nearby-page ripouts.
I don't have much time available, but let me take a crack at the
problem tonight. I don't think we want to add another workaround to
code that already has too many of them. The solution may be
to create a dummy placemarker vm_page_t and to insert it into the pagelist
just after the current page after we've locked it and decided we have
to do something significant to it. We would then be able to pick the
scan up where we left off using the placemarker.
This would allow us to get rid of the restart code entirely, or at least
devolve it back into its original design (i.e. something that would not
happen very often). Since we already have cache locality of reference for
the list node, the placemarker idea ought to be quite fast.
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.
-Matt
:
:Matt, I'm not sure if Paul mailed you yet so I thought I'd take the
:initiative of bugging you about some reported problems (lockups)
:when dealing with machines that have substantial MAP_NOSYNC'd
:data along with a page shortage.
:
:What seems to happen is that vm_pageout_scan (src/sys/vm/vm_pageout.c
:line 618) keeps rescanning the inactive queue.
:
:My guess is that it just doesn't expect someone to have hosed themselves
:by having so many pages that need laundering (maxlaunder/launder_loop)
:along with the fact that the comment and code here are doing the wrong
:thing for the situation:
:
: /*
: * Figure out what to do with dirty pages when they are encountered.
: * Assume that 1/3 of the pages on the inactive list are clean. If
: * we think we can reach our target, disable laundering (do not
: * clean any dirty pages). If we miss the target we will loop back
: * up and do a laundering run.
: */
:
: if (cnt.v_inactive_count / 3 > page_shortage) {
: maxlaunder = 0;
: launder_loop = 0;
: } else {
: maxlaunder =
: (cnt.v_inactive_target > max_page_launder) ?
: max_page_launder : cnt.v_inactive_target;
: launder_loop = 1;
: }
:
:The problem is that there's a chance that nearly all the pages on
:the inactive queue need laundering and the loop that starts with
:the lable 'rescan0:' is never able to clean enough pages before
:stumbling across a block that has moved to another queue. This
:forces a jump back to the 'rescan0' lable with effectively nothing
:accomplished.
:
:Here's a patch that may help, it's untested, but shows what I'm
:hoping to achieve which is force a maximum on the amount of times
:rescan0 will be jumped to while not laundering.
:...
:
:I'm pretty sure that there's yet another problem here, when paging
:out a vnode's pages the output routine attempts to cluster them,
:this could easily make 'next' point to a page that is cleaned and
:put on the FREE queue, when the loop then tests it for
:'m->queue != PQ_INACTIVE' it forces 'rescan0' to happen.
:
:I think one could fix this by keeping a pointer to the previous
:page then the 'goto rescan0;' test might become something like
:this:
:...
:
:Of course we need to set 'prev' properly, but I need to get back
:to my database stuff right now. :)
:
:Also... I wish there was a good hueristic to make max_page_launder
:a bit more adaptive, you've done some wonders with bufdaemon so
:I'm wondering if you had some ideas about that.
:
:--
:-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?200010242010.e9OKAJK19739>