If the read comes from block_read then the data goes into the page cache. If
it comes from getblk (because of physical readahead or "dd xxx >null") the
data goes into the buffer cache and may later be moved to the page cache,
once we know what the logical mapping is.
> Considering that the extra allocation and memcpy is likely to seriously
> degrade performance on any high-end hardware if it happens any noticeable
> percentage of the time, I don't see how your suggest can _ever_ be a win.
> The only time you avoid the memcpy is when you wasted the IO completely.
We don't have any extra allocation in the cases we're already handling now,
it works exactly the same. The only overhead is an extra hash probe on cache
miss.
> So please explain to me how you think this is all a good idea? Or explain
> why you think the memcpy is not going to be noticeable in disk throughput
> for normal loads?
When we're forced to do a memcpy it's for a case where we're saving a read or
a seek. Even then, the memcpy can be optimized away in the common case that
the blocksize matches page_size. Sometimes, even when the blocksize doesn't
match this optimization would be possible. But the memcpy optimization isn't
important, the goal is to save reads and seeks by combining reads and reading
blocks in physical order as opposed to file order.
An observation: logical readahead can *never* read a block before it knows
what the physical mapping is, whereas physical readahead can.
-- Daniel - 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/