linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Cc: Hugh Dickins <hughd@google.com>, Andrea Arcangeli <aarcange@redhat.com>
Subject: [LSF/MM TOPIC] THP, huge tmpfs, khugepaged
Date: Thu, 18 Feb 2016 13:06:12 +0200	[thread overview]
Message-ID: <20160218110612.GA27764@node.shutemov.name> (raw)

Hi,

I would like to attend LSF/MM 2016.

THP refcounting rework had been merged into v4.5 and I would like to
discuss next steps on THP front.

== huge tmpfs ==

One of the topic would be huge tmpfs. Currently we have two alternative
implementation of huge pages support in tmpfs:

  - Hugh has implemented it on top of new way to couple pages together --
    team pages. It's rather mature implementation which has been used in
    production.

  - I've implemented huge tmpfs on top of the same compound pages we use
    for THP. It's still under validation and hasn't got proper review.
    Few more iterations would be required to get it into shape.

Supporting two parallel implementation of the same feature is wasteful.
During the summit I would like to work out a consensus on what
implementation fits upstream more.

== khugepaged ==

Other topic I would like to talk about is khugepaged. New THP refcounting
opens some possibilities in this area.

We've got split_huge_pmd() decoupled from splitting underlying compound
page. We can separate collapse into two stages too: first collapse small
pages into a huge one, and then replace PTE tables with PMDs where it's
possible.

Even if the second stage has failed for some reason, we would still
benefit from fewer pages on LRU to deal with.

It also allows to collapse pages shared over fork(), which we cannot do at
the moment.

I personally would not have time to implement it any time soon, but I'll
help to anyone who wants to play with the idea.

-- 
 Kirill A. Shutemov

--
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:[~2016-02-18 11:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 11:06 Kirill A. Shutemov [this message]
2016-02-29  0:36 ` Hugh Dickins

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=20160218110612.GA27764@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=aarcange@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox