Matthew> So yes, I think within the next year, you should be Matthew> able to tell the page cache to allocate 4MB pages. I can't find the ascii thumbs up emoji :-) ... -Mike On Sat, Apr 4, 2020 at 1:43 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Sat, Apr 04, 2020 at 12:28:26PM -0400, hubcap@xxxxxxxxxx wrote: > > As an aside, the page cache has been a blessing and a curse > > for us. Since we started using it, small IO has improved > > incredibly, but our max speed hits a plateau before it otherwise > > would have. I think because of all the page size copies we have > > to do to fill our 4 meg native buffers. I try to read about all > > the new work going into the page cache in lwn, and make some > > sense of the new code :-). One thing I remember is when > > Christoph Lameter said "the page cache does not scale", but > > I know the new work is focused on that. If anyone has any > > thoughts about how we could make improvments on filling our > > native buffers from the page cache (larger page sizes?), > > feel free to offer any help... > > Umm, 4MB native buffers are ... really big ;-) I wasn't planning on > going past PMD_SIZE (ie 2MB on x86) for the readahead large pages, > but if a filesystem wants that, then I should change that plan. > > What I was planning for, but don't quite have an implementation nailed > down for yet, is allowing filesystems to grow the readahead beyond that > wanted by the generic code. Filesystems which implement compression > frequently want blocks in the 256kB size range. It seems like OrangeFS > would fit with that scheme, as long as I don't put a limit on what the > filesystem asks for. > > So yes, I think within the next year, you should be able to tell the > page cache to allocate 4MB pages. You will still need a fallback path > for when memory is too fragmented to allocate new pages, but if you're > using 4MB pages, then hopefully we'll be able to reclaim a clean 4MB > pages from elsewhere in the page cache and supply you with a new one.
