All of lore.kernel.org
 help / color / mirror / Atom feed
From: willy@bombadil.infradead.org
To: Jan Kara <jack@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [Lsf-pc] [ATTEND] many topics
Date: Wed, 18 Jan 2017 03:26:07 -0800	[thread overview]
Message-ID: <20170118112605.GC29472@bombadil.infradead.org> (raw)
In-Reply-To: <20170118101343.GC24789@quack2.suse.cz>

On Wed, Jan 18, 2017 at 11:13:43AM +0100, Jan Kara wrote:
> On Tue 17-01-17 21:49:45, Matthew Wilcox wrote:
> > 1. Exploiting multiorder radix tree entries.  I believe we would do well
> > to attempt to allocate compound pages, insert them into the page cache,
> > and expect filesystems to be able to handle filling compound pages with
> > ->readpage.  It will be more efficient because alloc_pages() can return
> > large entries out of the buddy list rather than breaking them down,
> > and it'll help reduce fragmentation.
> 
> Kirill has patches to do this and I don't like the complexity it adds to
> pagecache handling code and each filesystem that would like to support
> this. I don't have objections to the general idea but the complexity of the
> current implementation just looks too big to me...

Interesting.  Dave Chinner opined to me today that it was about 20 lines
of code in XFS, so somebody is missing something.

> > 2. Supporting filesystem block sizes > page size.  Once we do the above
> > for efficiency, I think it then becomes trivial to support, eg 16k block
> > size filesystems on x86 machines with 4k pages.
> 
> Heh, you wish... :) There's a big difference between opportunistically
> allocating a huge page and reliably have to provide high order page. Memory
> fragmentation issues will be difficult to deal with...

If you're mixing a lot of order-0 allocations with a few order-4
allocations, then yes memory fragmentation may become a problem.  But if
you're doing a lot of order-4 allocations, then it should be possible
to free an order-4 allocation from the inactive list of one of the files
on the 64k filesystem.

Somewhat related, and this question was asked during my talk today so
I should have mentioned it in the email, should order-9 pages on the
inactive list be treated differently from order-0 entries?  I suspect
the answer is yes, because there's probably little point in freeing
order-9 page off the LRU list in order to satisfy a order-9 allocation;
we should just find an order-9 page and free it.  Likewise, freeing an
order-9 page in order to satisfy an order-0 allocation is going to lead
to fragmentation and should probably be avoided.

I suspect order-0 and order-9 entries can be profitably mixed on the
active list, but it might be better to have separate LRU lists for normal
and huge pages.  Does it make sense to have one LRU list per order?
Maybe not go quite that far, but organising the inactive list by size
seems to have some merit.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-01-18 11:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  5:49 [ATTEND] many topics Matthew Wilcox
2017-01-18 10:13 ` [Lsf-pc] " Jan Kara
2017-01-18 11:26   ` willy [this message]
2017-01-18 13:32 ` Michal Hocko
2017-01-19 11:05   ` willy
2017-01-19 11:33     ` Michal Hocko
2017-01-19 11:52       ` willy
2017-01-19 12:11         ` Michal Hocko
2017-01-21  0:11           ` NeilBrown
2017-01-21 13:16             ` Theodore Ts'o
2017-01-22  4:45               ` NeilBrown
2017-01-23  6:05                 ` Matthew Wilcox
2017-01-23  6:30                   ` NeilBrown
2017-01-23  6:35                     ` Matthew Wilcox
2017-01-23 17:09                   ` Theodore Ts'o
2017-01-23 19:34                     ` NeilBrown
2017-01-25 14:36                       ` Vlastimil Babka
2017-01-25 20:36                         ` Matthew Wilcox
2017-01-25 21:15                           ` Vlastimil Babka
2017-01-25 23:19                         ` NeilBrown
2017-01-26  8:56                           ` Michal Hocko
2017-01-26 21:20                             ` NeilBrown
2017-01-27 13:12                               ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170118112605.GC29472@bombadil.infradead.org \
    --to=willy@bombadil.infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.