Re: Large PAGE_SIZE

[Hugh Dickins <hugh@veritas.com>]

On Thu, 5 Jul 2001, Linus Torvalds wrote:
> 
> Also note that the I/O _would_ happen in PAGE_CACHE_SIZE - you'd never
> break it into smaller chunks. That's the whole point of having a bigger
> PAGE_CACHE_SIZE.

Aha, are you saying that a part of the multipage PAGE_CACHE_SIZE project
is to go through the block layer and driver layer, changing appropriate
"PAGE_SIZE"s to "PAGE_CACHE_SIZE"s (whereas at present PAGE_CACHE_SIZE
is pretty much confined to the FS layer), so that the I/O isn't split?

If so, then yes indeed, the two approaches seem two sides of same coin:
I'd be changing one set of PAGE_SIZEs to VM_PAGE_SIZEs, while Ben would
be changing many of the others to PAGE_CACHE_SIZEs!  We'd differ at the
the user space level, but it might not amount to much (already we're both
filling multiple ptes on one fault).  I couldn't see what was going to
happen to the swap cache, if the anon pages were small but the cache size
large; but maybe swap readahead would dissolve our differences there too.

If not, please clarify.

> I'd really like both of you to think about both of the approaches as the
> same thing, but with different mindsets. Maybe there is something that
> clearly makes one mindset better. And maybe there is some way to just make
> the two be completely equivalent..

Yes, certainly I went about it in the only way I safely could, coming
from a VM background; someone with greater FS or I/O experience might
approach it differently.

It may come down to Ben having 2**N more struct pages than I do:
greater flexibility, but significant waste of kernel virtual.

I want to ponder the points in your mail: I'm a slow thinker and this
isn't intended as a reply, but I wanted to clarify PAGE_CACHE_SIZE I/O.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/