linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	alex.shi@linux.alibaba.com, cai@lca.pw, hannes@cmpxchg.org,
	linux-mm@kvack.org, mhocko@suse.com, mike.kravetz@oracle.com,
	mm-commits@vger.kernel.org, shakeelb@google.com,
	shy828301@gmail.com, stable@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: Re: [patch 04/15] shmem: shmem_writepage() split unlikely i915 THP
Date: Sat, 10 Oct 2020 16:32:36 +0100	[thread overview]
Message-ID: <20201010153236.GY20115@casper.infradead.org> (raw)
In-Reply-To: <877drz95pa.fsf@yhuang-dev.intel.com>

On Fri, Oct 09, 2020 at 04:14:25PM +0800, Huang, Ying wrote:
> Matthew Wilcox <willy@infradead.org> writes:
> > On Sat, Sep 19, 2020 at 05:18:47PM +0100, Matthew Wilcox wrote:
> >> On Fri, Sep 18, 2020 at 10:44:32PM -0700, Hugh Dickins wrote:
> >> > It behaves a lot better with this patch in than without it; but you're
> >> > right, only the head will get written to swap, and the tails left in
> >> > memory; with dirty cleared, so they may be left indefinitely (I've
> >> > not yet looked to see when if ever PageDirty might get set later).
> >> > 
> >> > Hmm. It may just be a matter of restyling the i915 code with
> >> > 
> >> > 		if (!page_mapped(page)) {
> >> > 			clear_page_dirty_for_io(page);
> >> > 
> >> > but I don't want to rush to that conclusion - there might turn
> >> > out to be a good way of doing it at the shmem_writepage() end, but
> >> > probably only hacks available.  I'll mull it over: it deserves some
> >> > thought about what would suit, if a THP arrived here some other way.
> >> 
> >> I think the ultimate solution is to do as I have done for iomap and make
> >> ->writepage handle arbitrary sized pages.  However, I don't know the
> >> swap I/O path particularly well, and I would rather not learn it just yet.
> >> 
> >> How about this for a band-aid until we sort that out properly?  Just mark
> >> the page as dirty before splitting it so subsequent iterations see the
> >> subpages as dirty.  Arguably, we should use set_page_dirty() instead of
> >> SetPageDirty, but I don't think i915 cares.  In particular, it uses
> >> an untagged iteration instead of searching for PAGECACHE_TAG_DIRTY.
> >> 
> >> diff --git a/mm/shmem.c b/mm/shmem.c
> >> index 271548ca20f3..6231207ab1eb 100644
> >> --- a/mm/shmem.c
> >> +++ b/mm/shmem.c
> >> @@ -1362,8 +1362,21 @@ static int shmem_writepage(struct page *page, struct writeback_control *wbc)
> >>  	swp_entry_t swap;
> >>  	pgoff_t index;
> >>  
> >> -	VM_BUG_ON_PAGE(PageCompound(page), page);
> >>  	BUG_ON(!PageLocked(page));
> >> +
> >> +	/*
> >> +	 * If /sys/kernel/mm/transparent_hugepage/shmem_enabled is "force",
> >> +	 * then drivers/gpu/drm/i915/gem/i915_gem_shmem.c gets huge pages,
> >> +	 * and its shmem_writeback() needs them to be split when swapping.
> >> +	 */
> >> +	if (PageTransCompound(page)) {
> >> +		/* Ensure the subpages are still dirty */
> >> +		SetPageDirty(page);
> >> +		if (split_huge_page(page) < 0)
> >> +			goto redirty;
> >> +		ClearPageDirty(page);
> >> +	}
> >> +
> >>  	mapping = page->mapping;
> >>  	index = page->index;
> >>  	inode = mapping->host;
> >
> > It turns out that I have an entirely different reason for wanting
> > ->writepage to handle an unsplit page.  In vmscan.c:shrink_page_list(),
> > we currently try to split file-backed THPs.  This always fails for XFS
> > file-backed THPs because they have page_private set which increments
> > the refcount by 1.  And so we OOM when the page cache is full of XFS
> > THPs.  I've been running successfully for a few days with this patch:
> >
> > @@ -1271,10 +1271,6 @@ static unsigned int shrink_page_list(struct list_head *page_list,
> >                                 /* Adding to swap updated mapping */
> >                                 mapping = page_mapping(page);
> >                         }
> > -               } else if (unlikely(PageTransHuge(page))) {
> > -                       /* Split file THP */
> > -                       if (split_huge_page_to_list(page, page_list))
> > -                               goto keep_locked;
> >                 }
> >  
> >                 /*
> >
> >
> > Kirill points out that this will probably make shmem unhappy (it's
> > possible that said pages will get split anyway if they're mapped
> > because we pass TTU_SPLIT_HUGE_PMD into try_to_unmap()), but if
> > they're (a) Dirty, (b) !mapped, we'll call pageout() which calls
> > ->writepage().
> 
> We may distinguish the shmem THPs from the XFS file cache THPs via
> PageSwapBacked()?

Yes, we _can_, but we now have two reasons for wanting to be able to write
THPs to swap without splitting them.  Another thing this solves is that,
in my tree, we don't allocate the bottom layer of the XArray for THPs.
So when we split, we have to allocate memory to store the split pages,
and it seems like a bad idea to allocate memory in order to free memory,
particularly when we don't have to.


  reply	other threads:[~2020-10-10 15:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-19  4:19 incoming Andrew Morton
2020-09-19  4:20 ` [patch 01/15] mailmap: add older email addresses for Kees Cook Andrew Morton
2020-09-19  4:20 ` [patch 02/15] ksm: reinstate memcg charge on copied pages Andrew Morton
2020-09-19  4:20 ` [patch 03/15] mm: migration of hugetlbfs page skip memcg Andrew Morton
2020-09-19  4:20 ` [patch 04/15] shmem: shmem_writepage() split unlikely i915 THP Andrew Morton
2020-09-19  4:44   ` Matthew Wilcox
2020-09-19  5:44     ` Hugh Dickins
2020-09-19 16:18       ` Matthew Wilcox
2020-09-20  0:16         ` Hugh Dickins
2020-09-20  3:32           ` Matthew Wilcox
2020-10-02 18:37         ` Matthew Wilcox
2020-10-09  8:14           ` Huang, Ying
2020-10-10 15:32             ` Matthew Wilcox [this message]
2020-10-12  2:01               ` Huang, Ying
2020-09-19  4:20 ` [patch 05/15] mm: fix check_move_unevictable_pages() on THP Andrew Morton
2020-09-19  4:20 ` [patch 06/15] mlock: fix unevictable_pgs event counts " Andrew Morton
2020-09-19  4:20 ` [patch 07/15] tmpfs: restore functionality of nr_inodes=0 Andrew Morton
2020-09-19  4:20 ` [patch 08/15] kprobes: fix kill kprobe which has been marked as gone Andrew Morton
2020-09-19  4:20 ` [patch 09/15] mm/thp: fix __split_huge_pmd_locked() for migration PMD Andrew Morton
2020-09-19  4:20 ` [patch 10/15] selftests/vm: fix display of page size in map_hugetlb Andrew Morton
2020-09-19  4:20 ` [patch 11/15] mm/memory_hotplug: drain per-cpu pages again during memory offline Andrew Morton
2020-09-19  4:20 ` [patch 12/15] ftrace: let ftrace_enable_sysctl take a kernel pointer buffer Andrew Morton
2020-09-19  4:20 ` [patch 13/15] stackleak: let stack_erasing_sysctl " Andrew Morton
2020-09-19  4:20 ` [patch 14/15] fs/fs-writeback.c: adjust dirtytime_interval_handler definition to match prototype Andrew Morton
2020-09-19  4:20 ` [patch 15/15] kcsan: kconfig: move to menu 'Generic Kernel Debugging Instruments' Andrew Morton

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=20201010153236.GY20115@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=cai@lca.pw \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).