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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
