Date: Wed, 11 Dec 1996 01:26:53 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: dyson@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/ufs/ufs ufs_readwrite.c Message-ID: <199612110626.BAA00187@dyson.iquest.net> In-Reply-To: <2419.850284036@time.cdrom.com> from "Jordan K. Hubbard" at Dec 10, 96 10:00:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > makes MADV_SEQUENTIAL much more effective. I suggest that > > we start using MADV_SEQUENTIAL on system utilities that mmap > > their input files, and the I/O is predominantely sequential. > > I was wondering whether or not cp(1) would benefit from this, then I > noticed that its mmap() handling had been made conditional on > VM_AND_BUFFER_CACHE_SYNCHRONIZED, which is not defined. I thought > they had been for a long time. :-) > I was considering enabling the mmap for reads on cp. However, I think that the 8MB limit as in cp is a bit arbitrary. I really don't know the right limit (perhaps the rlimit value is a good guess -- with an arbitrary ceiling of 8MB???) Since cp is used so often, I feel that making the change with more deliberation is wise. cmp already had terrible perf, as BDE pointed out to me, and that is what motivated me to fix it where it was broken. (We could have disabled mmap in cmp, but that is just sweeping it under the rug :-)). > > Or is this #ifdef just poorly named? Would > At one time (in the original Lite/2 code and in it's essentially unmodified derivatives), the buffer cache and VM object could get out of sync -- and strange things could happen. I wouldn't be suprised if some of the other Lite, Lite/2 derivatives are still susceptable to problems. We haven't had problems with things that the cp command does probably since 2.1.0 or somesuch timeframe. NFS has been problematical longer than local filesystems. (BTW, hopefully, I'll have a reasonable test setup for NFS after Christmas.) > > #ifdef MMAP_ACTUALLY_BOUGHT_US_PERFORMANCE > .. > #endif > > Be more appropriate? > For us, since 2.1.X, I think that your suggested name is more accurate. Also, I do think that we'll generally see marginally improved perf now since the recent change. Note that if you enable it in your private sources, you will likely want to do the madvise -- if you don't, the perf will be just as lousy as it was before. I would really like to enable it in -current, and the thing that I am waiting on is to come up with a good heuristic for the limit to switch between mmap and read/write... The problem is subtile, but mmaped entities can compete with VM space more aggressively than the non-mmaped entities left over from cycling through the wired part of the buffer cache. This is something that I do want to consult with DG, et. al. on. For funzies, we could just enable it though -- additionally, I have been running with mmap enabled on cp for the last yr or so, (trying to test a little before foisting it on others :-)). John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612110626.BAA00187>