On Mon, Feb 24, 2020 at 01:43:47PM -0800, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 07:57:27AM -0800, Christoph Hellwig wrote: > > On Thu, Feb 20, 2020 at 07:54:52AM -0800, Matthew Wilcox wrote: > > > On Thu, Feb 20, 2020 at 07:46:58AM -0800, Christoph Hellwig wrote: > > > > On Thu, Feb 20, 2020 at 05:48:49AM -0800, Matthew Wilcox wrote: > > > > > btrfs: Convert from readpages to readahead > > > > > > > > > > Implement the new readahead method in btrfs. Add a readahead_page_batch() > > > > > to optimise fetching a batch of pages at once. > > > > > > > > Shouldn't this readahead_page_batch heper go into a separate patch so > > > > that it clearly stands out? > > > > > > I'll move it into 'Put readahead pages in cache earlier' for v8 (the > > > same patch where we add readahead_page()) > > > > One argument for keeping it in a patch of its own is that btrfs appears > > to be the only user, and Goldwyn has a WIP conversion of btrfs to iomap, > > so it might go away pretty soon and we could just revert the commit. > > > > But this starts to get into really minor details, so I'll shut up now :) > > So looking at this again I have another comment and a question. > > First I think the implicit ARRAY_SIZE in readahead_page_batch is highly > dangerous, as it will do the wrong thing when passing a pointer or > function argument. somebody already thought of that ;-) #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr)) > Second I wonder іf it would be worth to also switch to a batched > operation in iomap if the xarray overhead is high enough. That should > be pretty trivial, but we don't really need to do it in this series. I've also considered keeping a small array of pointers inside the readahead_control so nobody needs to have a readahead_page_batch() operation. Even keeping 10 pointers in there will reduce the XArray overhead by 90%. But this fit the current btrfs model well, and it lets us play with different approaches by abstracting everything away. I'm sure this won't be the last patch that touches the readahead code ;-)
