Thread (67 messages) 67 messages, 4 authors, 2017-02-13

Re: [PATCHv6 11/37] HACK: readahead: alloc huge pages, if allowed

From: Matthew Wilcox <willy@infradead.org>
Date: 2017-02-09 23:34:36
Also in: linux-ext4, linux-fsdevel, linux-mm, lkml

On Thu, Jan 26, 2017 at 02:57:53PM +0300, Kirill A. Shutemov wrote:
Most page cache allocation happens via readahead (sync or async), so if
we want to have significant number of huge pages in page cache we need
to find a ways to allocate them from readahead.

Unfortunately, huge pages doesn't fit into current readahead design:
128 max readahead window, assumption on page size, PageReadahead() to
track hit/miss.

I haven't found a ways to get it right yet.

This patch just allocates huge page if allowed, but doesn't really
provide any readahead if huge page is allocated. We read out 2M a time
and I would expect spikes in latancy without readahead.

Therefore HACK.

Having that said, I don't think it should prevent huge page support to
be applied. Future will show if lacking readahead is a big deal with
huge pages in page cache.

Any suggestions are welcome.
Well ... what if we made readahead 2 hugepages in size for inodes which
are using huge pages?  That's only 8x our current readahead window, and
if you're asking for hugepages, you're accepting that IOs are going to
be larger, and you probably have the kind of storage system which can
handle doing larger IOs.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help