On Sun, 2007-07-22 at 18:33 +1000, Rusty Russell wrote: > On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote: > > - 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. > > I'm still not convinced of the latter case. If a second user accesses > the file before it pages are thrown out, from my understanding there > won't be readahead but the pages will be put back on the active list > (ie. the dropbehind is undone). > > AFAICT this patch truly biasses towards releasing pages from > sequentially accessed files. So file servers where memory pressure > comes from lots of such files should be fine (bias will work correctly > against least-served files). > > The main problem I can see is a low-memory server where we are currently > swapping out pages from non-sequential files (eg. gigantic running java > apps), and now performance might decline because we'll discard file > pages first. > > > So I opt for it being made tunable, safe, and turned off by default. > > I'd like to see it turned on by default in -mm, and try to come up with > some server-like workload to measure the effect. Should be easy to > simulate something (eg. apache server, where clients grab some files in > preference, and apache server where clients grab different files). > > Peter?
I guess we could do that. Just populate the server with a lot of randomly sized files, and make a client do a random pull or one with a poisson distribution or something like that. - 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/
