From owner-freebsd-hackers Fri Feb 22 9:16:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 5CBEA37B419 for ; Fri, 22 Feb 2002 09:16:52 -0800 (PST) Received: from andrewm by chiark.greenend.org.uk with local (Exim 3.12 #2) id 16eJJO-00044H-00 (Debian); Fri, 22 Feb 2002 17:16:46 +0000 From: Andrew Mobbs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15478.31998.459219.178549@chiark.greenend.org.uk> Date: Fri, 22 Feb 2002 17:16:46 +0000 (GMT) To: hackers@freebsd.org Subject: msync performance X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I recently raised PR 35195 Details are in the PR, but in summary; performing a large amount of random IO to a large file through mmap, on a machine with a fair amount of free RAM, will cause a following msync to take a significant amount of time. I believe this is because msync walks the dirty buffer list by age, therefor will write blocks out in an order liable to cause a lot of disk seeks. My suggestion for a solution would be before starting the IO, to sort the dirty buffer list by location on logical disk, and coalesce adjacent blocks where possible. Before I volunteer to implement something like this, please could somebody check I'm correct in my analysis, and comment on the feasibility of my suggested solution. Thanks, -- Andrew Mobbs - http://www.chiark.greenend.org.uk/~andrewm/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message