All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zi Yan <zi.yan@sent.com>
To: Matthew Wilcox <willy@infradead.org>, linux-mm@kvack.org
Cc: Roman Gushchin <roman.gushchin@linux.dev>,
	Shuah Khan <shuah@kernel.org>, Yang Shi <shy828301@gmail.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Hugh Dickins <hughd@google.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-kselftest@vger.kernel.org, Zi Yan <ziy@nvidia.com>
Subject: [RFC PATCH 0/5] Split a huge page to any lower order pages
Date: Mon, 21 Mar 2022 10:21:23 -0400	[thread overview]
Message-ID: <20220321142128.2471199-1-zi.yan@sent.com> (raw)

From: Zi Yan <ziy@nvidia.com>

Hi all,

With Matthew's huge pagecache page patches merged, we are able to handle any
size pagecache pages, but currently split_huge_page can only split a huge page
to order-0 pages. This can easily erase the benefit of having huge pagecache
pages, when operations like truncate might want to keep pages larger than
order-0. In response, here is the patches to add support for splitting a huge
page to any lower order pages.

The patchset is on top of mmotm-2022-03-16-17-42.

* Patch 1 and 2 add new_order parameter split_page_memcg() and
  split_page_owner() and prepare for upcoming changes.
* Patch 3 adds split_huge_page_to_list_to_order() to split a huge page
  to any lower order. The original split_huge_page_to_list() calls
  split_huge_page_to_list_to_order() with new_order = 0.
* Patch 4 uses split_huge_page_to_list_to_order() in huge pagecache page
  truncation instead of split the huge page all the way down to order-0.
* Patch 5 adds a test API to debugfs and test cases in
  split_huge_page_test selftests.

Comments and/or suggestions are welcome.

Zi Yan (5):
  mm: memcg: make memcg huge page split support any order split.
  mm: page_owner: add support for splitting to any order in split
    page_owner.
  mm: thp: split huge page to any lower order pages.
  mm: truncate: split huge page cache page to a non-zero order if
    possible.
  mm: huge_memory: enable debugfs to split huge pages to any order.

 include/linux/huge_mm.h                       |   8 +
 include/linux/memcontrol.h                    |   2 +-
 include/linux/page_owner.h                    |  12 +-
 mm/huge_memory.c                              | 139 +++++++----
 mm/memcontrol.c                               |  10 +-
 mm/page_alloc.c                               |   4 +-
 mm/page_owner.c                               |  13 +-
 mm/truncate.c                                 |  33 ++-
 .../selftests/vm/split_huge_page_test.c       | 219 +++++++++++++++---
 9 files changed, 347 insertions(+), 93 deletions(-)

-- 
2.35.1


WARNING: multiple messages have this Message-ID (diff)
From: Zi Yan <zi.yan-vRdzynncJC4@public.gmane.org>
To: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
Cc: Roman Gushchin
	<roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>,
	Shuah Khan <shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Yang Shi <shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Miaohe Lin <linmiaohe-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	"Kirill A . Shutemov"
	<kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Zi Yan <ziy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: [RFC PATCH 0/5] Split a huge page to any lower order pages
Date: Mon, 21 Mar 2022 10:21:23 -0400	[thread overview]
Message-ID: <20220321142128.2471199-1-zi.yan@sent.com> (raw)

From: Zi Yan <ziy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Hi all,

With Matthew's huge pagecache page patches merged, we are able to handle any
size pagecache pages, but currently split_huge_page can only split a huge page
to order-0 pages. This can easily erase the benefit of having huge pagecache
pages, when operations like truncate might want to keep pages larger than
order-0. In response, here is the patches to add support for splitting a huge
page to any lower order pages.

The patchset is on top of mmotm-2022-03-16-17-42.

* Patch 1 and 2 add new_order parameter split_page_memcg() and
  split_page_owner() and prepare for upcoming changes.
* Patch 3 adds split_huge_page_to_list_to_order() to split a huge page
  to any lower order. The original split_huge_page_to_list() calls
  split_huge_page_to_list_to_order() with new_order = 0.
* Patch 4 uses split_huge_page_to_list_to_order() in huge pagecache page
  truncation instead of split the huge page all the way down to order-0.
* Patch 5 adds a test API to debugfs and test cases in
  split_huge_page_test selftests.

Comments and/or suggestions are welcome.

Zi Yan (5):
  mm: memcg: make memcg huge page split support any order split.
  mm: page_owner: add support for splitting to any order in split
    page_owner.
  mm: thp: split huge page to any lower order pages.
  mm: truncate: split huge page cache page to a non-zero order if
    possible.
  mm: huge_memory: enable debugfs to split huge pages to any order.

 include/linux/huge_mm.h                       |   8 +
 include/linux/memcontrol.h                    |   2 +-
 include/linux/page_owner.h                    |  12 +-
 mm/huge_memory.c                              | 139 +++++++----
 mm/memcontrol.c                               |  10 +-
 mm/page_alloc.c                               |   4 +-
 mm/page_owner.c                               |  13 +-
 mm/truncate.c                                 |  33 ++-
 .../selftests/vm/split_huge_page_test.c       | 219 +++++++++++++++---
 9 files changed, 347 insertions(+), 93 deletions(-)

-- 
2.35.1


             reply	other threads:[~2022-03-21 14:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 14:21 Zi Yan [this message]
2022-03-21 14:21 ` [RFC PATCH 0/5] Split a huge page to any lower order pages Zi Yan
2022-03-21 14:21 ` [RFC PATCH 1/5] mm: memcg: make memcg huge page split support any order split Zi Yan
2022-03-21 14:21   ` Zi Yan
2022-03-21 18:57   ` Roman Gushchin
2022-03-21 18:57     ` Roman Gushchin
2022-03-21 19:07     ` Zi Yan
2022-03-21 19:07       ` Zi Yan
2022-03-21 19:54       ` Matthew Wilcox
2022-03-21 19:54         ` Matthew Wilcox
2022-03-21 20:26         ` Zi Yan
2022-03-21 20:26           ` Zi Yan
2022-03-21 14:21 ` [RFC PATCH 2/5] mm: page_owner: add support for splitting to any order in split page_owner Zi Yan
2022-03-21 14:21   ` Zi Yan
2022-03-21 19:02   ` Roman Gushchin
2022-03-21 19:02     ` Roman Gushchin
2022-03-21 19:08     ` Zi Yan
2022-03-21 19:08       ` Zi Yan
2022-03-21 14:21 ` [RFC PATCH 3/5] mm: thp: split huge page to any lower order pages Zi Yan
2022-03-21 14:21   ` Zi Yan
2022-03-21 22:18   ` Roman Gushchin
2022-03-21 22:18     ` Roman Gushchin
2022-03-22 14:21     ` Zi Yan
2022-03-22 14:21       ` Zi Yan
2022-03-22  3:21   ` Miaohe Lin
2022-03-22  3:21     ` Miaohe Lin
2022-03-22 14:30     ` Zi Yan
2022-03-22 14:30       ` Zi Yan
2022-03-23  2:31       ` Miaohe Lin
2022-03-23  2:31         ` Miaohe Lin
2022-03-23 22:10         ` Zi Yan
2022-03-24  2:02           ` Miaohe Lin
2022-03-24  2:02             ` Miaohe Lin
2022-03-22 20:57   ` Yang Shi
2022-03-21 14:21 ` [RFC PATCH 4/5] mm: truncate: split huge page cache page to a non-zero order if possible Zi Yan
2022-03-21 14:21   ` Zi Yan
2022-03-21 22:32   ` Roman Gushchin
2022-03-21 22:32     ` Roman Gushchin
2022-03-22 14:19     ` Zi Yan
2022-03-22 14:19       ` Zi Yan
2022-03-23  6:40   ` [mm] 2757cee2d6: UBSAN:shift-out-of-bounds_in_include/linux/log2.h kernel test robot
2022-03-23  6:40     ` kernel test robot
2022-03-21 14:21 ` [RFC PATCH 5/5] mm: huge_memory: enable debugfs to split huge pages to any order Zi Yan
2022-03-21 14:21   ` Zi Yan
2022-03-21 22:23   ` Roman Gushchin
2022-03-21 22:23     ` Roman Gushchin

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=20220321142128.2471199-1-zi.yan@sent.com \
    --to=zi.yan@sent.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=roman.gushchin@linux.dev \
    --cc=shuah@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.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 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.