From: Rik van Riel <riel@fb.com>
To: Song Liu <songliubraving@fb.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "matthew.wilcox@oracle.com" <matthew.wilcox@oracle.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"Kernel Team" <Kernel-team@fb.com>,
"william.kucharski@oracle.com" <william.kucharski@oracle.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v4 6/6] mm,thp: avoid writes to file with THP in pagecache
Date: Thu, 20 Jun 2019 17:42:02 +0000 [thread overview]
Message-ID: <c29e2daf2e3c9c8acbdfae62ba8090f572d88345.camel@fb.com> (raw)
In-Reply-To: <20190620172752.3300742-7-songliubraving@fb.com>
On Thu, 2019-06-20 at 10:27 -0700, Song Liu wrote:
> +++ b/mm/mmap.c
> @@ -3088,6 +3088,18 @@ int vm_brk(unsigned long addr, unsigned long
> len)
> }
> EXPORT_SYMBOL(vm_brk);
>
> +static inline void release_file_thp(struct vm_area_struct *vma)
> +{
> +#ifdef CONFIG_READ_ONLY_THP_FOR_FS
> + struct file *file = vma->vm_file;
> +
> + if (file && (vma->vm_flags & VM_DENYWRITE) &&
> + atomic_read(&file_inode(file)->i_writecount) == 0 &&
> + filemap_nr_thps(file_inode(file)->i_mapping))
> + truncate_pagecache(file_inode(file), 0);
> +#endif
> +}
> +
> /* Release all mmaps. */
> void exit_mmap(struct mm_struct *mm)
> {
> @@ -3153,6 +3165,8 @@ void exit_mmap(struct mm_struct *mm)
> while (vma) {
> if (vma->vm_flags & VM_ACCOUNT)
> nr_accounted += vma_pages(vma);
> +
> + release_file_thp(vma);
> vma = remove_vma(vma);
> }
> vm_unacct_memory(nr_accounted);
I like how you make the file accessible again to other
users, but am somewhat unsure about the mechanism used.
First, if multiple processes have the same file mmapped,
do you really want to blow away the page cache?
Secondly, by hooking into exit_mmap, you miss making
files writable again that get unmapped through munmap.
Would it be better to blow away the page cache when
the last mmap user unmaps it?
The page->mapping->i_mmap interval tree will be empty
when nobody has the file mmap()d.
Alternatively, open() could check whether the file is
currently mmaped, and blow away the page cache then.
That would leave the page cache intact if the same file
gets execve()d several times in a row without any writes
in-between, which seems like it might be a relatively
common case.
prev parent reply other threads:[~2019-06-20 17:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 17:27 [PATCH v4 0/6] [PATCH v3 0/6] Enable THP for text section of non-shmem files Song Liu
2019-06-20 17:27 ` [PATCH v4 1/6] filemap: check compound_head(page)->mapping in filemap_fault() Song Liu
2019-06-20 17:27 ` [PATCH v4 2/6] filemap: update offset check " Song Liu
2019-06-20 17:27 ` [PATCH v4 3/6] mm,thp: stats for file backed THP Song Liu
2019-06-20 17:27 ` [PATCH v4 4/6] khugepaged: rename collapse_shmem() and khugepaged_scan_shmem() Song Liu
2019-06-20 17:27 ` [PATCH v4 5/6] mm,thp: add read-only THP support for (non-shmem) FS Song Liu
2019-06-20 17:33 ` Rik van Riel
2019-06-20 17:27 ` [PATCH v4 6/6] mm,thp: avoid writes to file with THP in pagecache Song Liu
2019-06-20 17:42 ` Rik van Riel [this message]
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=c29e2daf2e3c9c8acbdfae62ba8090f572d88345.camel@fb.com \
--to=riel@fb.com \
--cc=Kernel-team@fb.com \
--cc=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.wilcox@oracle.com \
--cc=songliubraving@fb.com \
--cc=william.kucharski@oracle.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).