Messages in this thread | | | Subject | Re: [PATCH 0/3] map multiple blocks in get_block() and mpage_readpages() | From | Badari Pulavarty <> | Date | Fri, 24 Feb 2006 09:19:08 -0800 |
| |
On Wed, 2006-02-22 at 16:12 +0100, christoph wrote: .. > Thanks Badari, with that interface changes the mpage_readpage changes > look a lot nicer than my original version. I'd like to second > the request to put it into -mm. > > And if the namesys folks could try out whether this works for their > reiser4 requirements it'd be nice. If you have an even faster > ->readpages I'd be interested in that secrete souce receipe for > further improvement to mpage_readpages.
I don't have any secret receipes, but I was thinking of re-organizing the code a little. Complexity is due to "confused" case and "blocksize < pagesize" cases + going in-and-out of the worker routine with stored state.
I am thinking of having a "fast path" which doesn't deal with any of those and "slow" path to deal with all that non-sense. Something like ..
mpage_readpages() { if (block-size < page-size) slow_path;
while (nr-pages) { if (get_block(bh)) slow_path; if (uptodate(bh)) slow_path; while (bh.b_size) { if (not contig) submit bio(); add all the pages we can to bio(); bh.b_size -= size-of-pages-added; nr_pages -= count-of-pages-added; }
} }
slow_path is going to be slow & ugly. How important is to handle 1k, 2k filesystems efficiently ? Should I try ? Thanks, Badari
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |