Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Feb 2002 10:10:08 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Andrew Mobbs <andrewm@chiark.greenend.org.uk>
Cc:        hackers@freebsd.org
Subject:   Re: msync performance
Message-ID:  <3C768980.F823B2D0@mindspring.com>
References:  <15478.31998.459219.178549@chiark.greenend.org.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C768980.F823B2D0>