From owner-freebsd-hackers Fri Feb 22 10:10:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 0808E37B402 for ; Fri, 22 Feb 2002 10:10:30 -0800 (PST) Received: from pool0467.cvx22-bradley.dialup.earthlink.net ([209.179.199.212] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16eK9C-000660-00; Fri, 22 Feb 2002 10:10:18 -0800 Message-ID: <3C768980.F823B2D0@mindspring.com> Date: Fri, 22 Feb 2002 10:10:08 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Mobbs Cc: hackers@freebsd.org Subject: Re: msync performance References: <15478.31998.459219.178549@chiark.greenend.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Andrew Mobbs wrote: > 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. Before jumping into it so heavily, note that msync schedules everything for write when len == 0, and has a couple of other bogosities that make it's performance suck in corner cases (e.g. clean pages are handled wrong). If you are exercising one of the corner cases, then it's going to exacerbate the problem. > 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. I think this would work, but I think there is other stuff in the performance path. Specifically, look at the comment on coelescing/splitting of regions in vm_mmap.c. It's probably still a win to do what you suggest, but if you dropped out the clean pages, you'd probably have a bunch of discontigous pages anyway, and the rotational latency would actually pessimize things. But avoiding the unnecessary seeks would probably make up for it. Basically, you'd have to test it by writing the code. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message