[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1A3A4BB5-C16B-4A11-AC90-420DDFE3D6F9@fb.com>
Date: Mon, 24 Jun 2019 21:17:47 +0000
From: Song Liu <songliubraving@...com>
To: Hillf Danton <hdanton@...a.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"matthew.wilcox@...cle.com" <matthew.wilcox@...cle.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
Kernel Team <Kernel-team@...com>,
"william.kucharski@...cle.com" <william.kucharski@...cle.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v7 5/6] mm,thp: add read-only THP support for
(non-shmem)FS
> On Jun 24, 2019, at 12:48 AM, Hillf Danton <hdanton@...a.com> wrote:
>
>
> Hello
>
> On Mon, 24 Jun 2019 12:28:32 +0800 Song Liu wrote:
>>
>> Hi Hillf,
>>
>>> On Jun 23, 2019, at 8:16 PM, Hillf Danton <hdanton@...a.com> wrote:
>>>
>>>
>>> Hello
>>>
>>> On Sun, 23 Jun 2019 13:48:47 +0800 Song Liu wrote:
>>>> This patch is (hopefully) the first step to enable THP for non-shmem
>>>> filesystems.
>>>>
>>>> This patch enables an application to put part of its text sections to THP
>>>> via madvise, for example:
>>>>
>>>> madvise((void *)0x600000, 0x200000, MADV_HUGEPAGE);
>>>>
>>>> We tried to reuse the logic for THP on tmpfs.
>>>>
>>>> Currently, write is not supported for non-shmem THP. khugepaged will only
>>>> process vma with VM_DENYWRITE. The next patch will handle writes, which
>>>> would only happen when the vma with VM_DENYWRITE is unmapped.
>>>>
>>>> An EXPERIMENTAL config, READ_ONLY_THP_FOR_FS, is added to gate this
>>>> feature.
>>>>
>>>> Acked-by: Rik van Riel <riel@...riel.com>
>>>> Signed-off-by: Song Liu <songliubraving@...com>
>>>> ---
>>>> mm/Kconfig | 11 ++++++
>>>> mm/filemap.c | 4 +--
>>>> mm/khugepaged.c | 90 ++++++++++++++++++++++++++++++++++++++++---------
>>>> mm/rmap.c | 12 ++++---
>>>> 4 files changed, 96 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>>> index f0c76ba47695..0a8fd589406d 100644
>>>> --- a/mm/Kconfig
>>>> +++ b/mm/Kconfig
>>>> @@ -762,6 +762,17 @@ config GUP_BENCHMARK
>>>>
>>>> See tools/testing/selftests/vm/gup_benchmark.c
>>>>
>>>> +config READ_ONLY_THP_FOR_FS
>>>> + bool "Read-only THP for filesystems (EXPERIMENTAL)"
>>>> + depends on TRANSPARENT_HUGE_PAGECACHE && SHMEM
>>>> +
>>> The ext4 mentioned in the cover letter, along with the subject line of
>>> this patch, suggests the scissoring of SHMEM.
>>
>> We reuse khugepaged code for SHMEM, so the dependency does exist.
>>
> On the other hand I see collapse_file() and khugepaged_scan_file(), and
> wonder if ext4 files can be handled by the new functions. If yes, we can
> drop that dependency in the game of RO thp to make ext4 be ext4, and
> shmem be shmem, as they are.
Ext4 files can be handled by these functions. We will need fs specific
code for writable THPs (in the future).
In longer term, once the code (with write support) become more stable,
we will drop this config. As of now, I think it is OK to depend on SHMEM.
Thanks,
Song
Powered by blists - more mailing lists