From owner-freebsd-hackers  Tue Oct 24 15:50:38 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4581D37B479; Tue, 24 Oct 2000 15:50:36 -0700 (PDT)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e9OMoZY22187;
	Tue, 24 Oct 2000 15:50:35 -0700 (PDT)
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>
References: <20001024112708.E28123@fw.wintelcom.net> <200010242010.e9OKAJK19739@earth.backplane.com> <20001024151414.P28123@fw.wintelcom.net> <200010242232.e9OMW1X21204@earth.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <200010242232.e9OMW1X21204@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Oct 24, 2000 at 03:32:01PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* 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