From owner-freebsd-hackers Tue Oct 24 16:39: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 1E97C37B479; Tue, 24 Oct 2000 16:39:16 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.0/8.9.3) id e9ONd1B21981; Tue, 24 Oct 2000 16:39:01 -0700 (PDT) (envelope-from dillon) Date: Tue, 24 Oct 2000 16:39:01 -0700 (PDT) From: Matt Dillon Message-Id: <200010242339.e9ONd1B21981@earth.backplane.com> To: Alfred Perlstein 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> <200010242232.e9OMW1X21204@earth.backplane.com> <20001024155035.Q28123@fw.wintelcom.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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