On Sat, Jul 21, 2007 at 10:44:28PM -0400, Dave Jones wrote: > On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote: > > > It makes sense to raise it beyond 128K. 1M default readahead > > absolutely makes sense for sequential workloads. For the desktop, > > this increases boot speed and readahead misses, both due to more > > aggressive mmap read-around. Most users will be glad to feel the > > speedup, and happily ignore the readahead misses, which may be > > "invisible" in case of large memory. > > > > In theory, the distributions can do the same tuning. So we have an > > interesting question for Dave: > > Does fedora desktop raise the default readahead size? Why or > > why not? It goes so far to do userland readahead ;) > > Fedora takes whatever defaults for readahead the kernel.org kernel has. > The only reasoning being if anyone reported VM bugs, we'd be able > to say to interested upstream developers "we're running the stock VM". > without having to get the user to try and reproduce on unpatched > kernels.
Thank you. Now I'm more confident that the kernel should have a reasonable default readahead size. The current one is 5+ years old and should be updated now. > > - drop behind > > > > Sorry, I still doubt it will benefit all/most workloads. Leave it off > > by default, and leave the enabling decision to Dave? I do hope that > > it help general desktops. > > It's not a subject that I'm intimatly familiar with, and when it > comes to decisions like this, I tend to just take whatever the > upstream defaults are. - It will avoid large-file-reads-thrashing-my-desktop problem, so most desktop users should like it. But sure there will be counter cases when a user want to keep the data cached. - File servers may hurt from it. Imagine a mp3/png file server. The files are large enough to trigger drop-behind, but small (and hot) enough to be cached. Also when a new fedora DVD iso is released, it may be cached for some days. These are only the obvious cases. So I opt for it being made tunable, safe, and turned off by default. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
