If you can find them....
> > The patch is not about forcing to use large pages but about the option to
No its a fact. The patchset really allows one to switch large page
support on and off. It opens up new options..
The page cache is different from pte mapping. One page struct controls
them all. Look at the patches. There is no state information in the tail
pages apart from pointing to the head page.
Pagecache != mmap.
The page cache functions require a mapping parameter. This is available
in most place and a natural thing given that allocation etc is also bound
to mapping information.
Not sure what you mean by that.
No they are 16k if the filesystem wants them to be 16k. The filesystem
does not need to have the data mapped into an address space. And there is
no problem with mapping 4k sections if we want to using the ptes.
No this code will enable us to switch to this new page size in a very fast
way. Because the pagecache already supports it it is easier to add the
mmap support for other page sizes.
The manufacturers on x86 are already supporting 2M page sizes and cannot
support intermediate sizes since they are married to the page table
format for performance reasons. The patch could f.e. lead to
straightforward support for 2M page mappings if we wanted it.
And I am sitting here in disbelief about the series of weird alternatives
running over my screen just to avoid the obvious solution. Then there is
this weird idea that this would hinder us from supporting additional page
sizes for mmap while the patch does exactly lead to enable support such
features in the future.
Where? The page cache handling in the various layers is significantly
simplified which reduces maintenance cost.
One? Spin.... The majority you mean?
Dave, where are we with the performance tests?
-
