Messages in this thread | | | Date | Mon, 21 Nov 2011 20:00:27 +0800 | From | Wu Fengguang <> | Subject | Re: [PATCH 0/8] readahead stats/tracing, backwards prefetching and more |
| |
On Mon, Nov 21, 2011 at 05:56:38PM +0800, Christoph Hellwig wrote: > On Mon, Nov 21, 2011 at 05:18:19PM +0800, Wu Fengguang wrote: > > Andrew, > > > > I'm getting around to pick up the readahead works again :-) > > > > This first series is mainly to add some debug facilities, to support the long > > missed backwards prefetching capability, and some old patches that somehow get > > delayed (shame me). > > > > The next step would be to better handle the readahead thrashing situations. > > That would require rewriting part of the algorithms, this is why I'd like to > > keep the backwards prefetching simple and stupid for now. > > > > When (almost) free of readahead thrashing, we'll be in a good position to lift > > the default readahead size. Which I suspect would be the single most efficient > > way to improve performance for the large volumes of casually maintained Linux > > file servers. > > Btw, if you work actively in that area I have a todo list item I was > planning to look into sooner or later: instead of embedding the ra > state into the struct file allocate it dynamically. That way files that > either don't use the pagecache, or aren't read from won't need have to > pay the price for increasing struct file size, and if we have to we > could enlarge it more easily.
Agreed. That's good to have, please allow me to move it into my todo list :)
> Besides removing f_version in the common > struct file and also allocting f_owner separately that seem to be the > easiest ways to get struct file size down.
Yeah, there seems no much code accessing fown_struct. I may consider that when I'm at file_ra_state, but no promise ;)
Thanks, Fengguang
| |