Messages in this thread | | | Date | Wed, 3 Jun 2009 13:47:39 -0700 | From | Andrew Morton <> | Subject | Re: mmotm 2009-06-02-16-11 uploaded (readahead) |
| |
On Tue, 02 Jun 2009 20:54:39 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> akpm@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2009-06-02-16-11 has been uploaded to > > > > http://userweb.kernel.org/~akpm/mmotm/ > > > > and will soon be available at > > > > git://git.zen-sources.org/zen/mmotm.git > > > readahead-add-blk_run_backing_dev.patch: > > mm/readahead.c: In function 'page_cache_async_readahead': > mm/readahead.c:559: error: implicit declaration of function 'blk_run_backing_dev'
hm, yeah, CONFIG_BLOCK=n.
Doing a block-specific call from inside page_cache_async_readahead() is a bit of a layering violation - this may not be a block-backed filesystem at all.
otoh, perhaps blk_run_backing_dev() is wrongly named and defined in the wrong place. Perhaps non-block-backed backing_devs want to implement an unplug-style function too? In which case the whole thing should be renamed and moved outside blkdev.h.
If we don't want to do that, shouldn't backing_dev_info.unplug* be wrapped in #ifdef CONFIG_BLOCK? And wasn't it a layering violation to put block-specific things into the backing_dev_info?
Jens, talk to me!
From the readahead POV: does it make sense to call the backing-dev's "unplug" function even if that isn't a block-based device? Or was this just a weird block-device-only performance problem? Hard to say.
| |