From owner-freebsd-hackers  Tue Oct 24 15:32:18 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135])
	by hub.freebsd.org (Postfix) with ESMTP
	id CF54A37B4C5; Tue, 24 Oct 2000 15:32:15 -0700 (PDT)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.0/8.9.3) id e9OMW1X21204;
	Tue, 24 Oct 2000 15:32:01 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 24 Oct 2000 15:32:01 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200010242232.e9OMW1X21204@earth.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: ps@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: vm_pageout_scan badness
References: <20001024112708.E28123@fw.wintelcom.net> <200010242010.e9OKAJK19739@earth.backplane.com> <20001024151414.P28123@fw.wintelcom.net>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


: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