Date: Tue, 24 Oct 2000 16:39:01 -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: <200010242339.e9ONd1B21981@earth.backplane.com> References: <20001024112708.E28123@fw.wintelcom.net> <200010242010.e9OKAJK19739@earth.backplane.com> <20001024151414.P28123@fw.wintelcom.net> <200010242232.e9OMW1X21204@earth.backplane.com> <20001024155035.Q28123@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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?
The async writes are competing against the rest of the system
for disk resources. While it is ok for an async write to stall, the
fact that it will cause other processes read() or page-in (which is
nominally synchronous) requests to stall can result in seriously
degraded operation for those processes.
Piling on the number of async writes running in parallel is not
going to improve the performance of page-out daemon, but it will
degrade the performance of I/O issued by other processes in the system.
The only two reasons the pageout daemon is not doing synchronous writes
are: (1) because it can't afford to stall on a slow device (or NFS, etc.)
and (2) so it can parallelize I/O across different devices. But since
the pageout daemon isn't really all that smart and doesn't track what it
does, the whole algorithm devolves into issueing a certain number of
asynchronous I/O's all at once.... governed by max_page_launder.
-Matt
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?200010242339.e9ONd1B21981>