Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc:     David Hildenbrand <david@redhat.com>,
        Michal Hocko <mhocko@suse.com>,
        Oscar Salvador <osalvador@suse.de>, Zi Yan <ziy@nvidia.com>,
        Muchun Song <songmuchun@bytedance.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        David Rientjes <rientjes@google.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
        Nghia Le <nghialm78@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Mike Kravetz <mike.kravetz@oracle.com>
Subject: [PATCH v4 0/5] hugetlb: add demote/split page functionality
Date:   Thu,  7 Oct 2021 11:19:13 -0700
Message-Id: <20211007181918.136982-1-mike.kravetz@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eQje2irVpbx2ylXIzmsdmDsOQpHqwAl0YCy1OFObb1AzBIvaO2D8G7zn285v?=
 =?us-ascii?Q?vazLvH5w+IoTlBNk5cN064qdpcSHMnAv8H0cQ4A0lrHcmQnnULW7V8KPxayo?=
 =?us-ascii?Q?Aw+i0ehUGpktGAe1gsI/1L3hcbojDOMvcdGOfqvX7Zo+5hQv3bcMWIOdZ9Xg?=
 =?us-ascii?Q?BHI8b4dIby4DwMeBiKjOQPBc0Ao9i55kZA20qp9l6RGJqtmwOGkGk/H3P98t?=
 =?us-ascii?Q?Q5RJwknUQYxaBd4tAdG47U9vUhxKzxx/KCIlgf8uK1WPcPtfWJWgmmykNK2q?=
 =?us-ascii?Q?+UFeqnk4faMmGPwO7lCjZbywh5yzFBOL3tW2H7bq+LBOr+FiwEXRFoPTRC7G?=
 =?us-ascii?Q?v5M4j9Xff56YOPKwYLi1MTs2dMxx94d2pJiZYfifmkJ4oTbk1+1z8Bb1bowR?=
 =?us-ascii?Q?QRtzoA9iWhqaGi2CYukeinfCenhdzQ0lX2tBUNUBydl0Y9/yDLW38sljRknT?=
 =?us-ascii?Q?FNHlw/VlCysJ+a72PZyyUti0Xij5NCbe1qA1FaPw+RZPI/A+LnSzTxEST+3s?=
 =?us-ascii?Q?KKRTMk0vK9x1yprZ5torQLmwdO//6UgZ+UgPL5mDinYIbLBGnlBk+8bVNq/s?=
 =?us-ascii?Q?Vcgh3wfMZ5n5QJHe388yhPCIEDkhQUYs5MfcVpkqCYSp3mQ/mMIZPpKwddpF?=
 =?us-ascii?Q?DN9Z0sV2ek3gUqtLCbYFGEgdZW+vrXMEKe1A+nm2t6JGca/iL/uzeQhCx5Og?=
 =?us-ascii?Q?cAyZTP2nDzYPpMvtRUjK1wXMyQcR5T3FjUTPbhhD6RRQDcG1DyaSgRI+jQiK?=
 =?us-ascii?Q?iT4KxOeesoBNuNZaXOa1e8W7LTR6BuR5CqXzvsmaBwSi7tbFI5sx968T0biZ?=
 =?us-ascii?Q?25egOvpLqPAu1S0iTKg/1xvNWrCrVoWCgYTpKndch1t6KiK7ttTyaNUJn7rG?=
 =?us-ascii?Q?ECjuSIfWV9iKEinAg40i7uc1vXHKgEKVuki3m1lfw01fw9Hh38KDx9hEhpsE?=
 =?us-ascii?Q?dgZwyBPfy8RH4Pubw2jdl0K1O2Azc1wU+t78Wa7ZMzeMrHcSWeGGfYCmYtm7?=
 =?us-ascii?Q?Xj9X0D17x5glWkiSJMGOWWHBG6uxBY3Xh16bY9o9oPA5SH4AB8XxlwZ+87qC?=
 =?us-ascii?Q?iqyHP3xHxE+V/1ahKx9ki/IynrvIi+iukIH5n3NTi6oJxjW2Hw4yNv2ritTp?=
 =?us-ascii?Q?MtEPEEha5YVvpc0hLhf6HMkKfgDhf7GxIGxnxQpE+oETLFz36EhtPt1nhL1M?=
 =?us-ascii?Q?4ZskNZu4YFxPL0Y3+Sq3i3EhSHUT74yRVbl/AqLmeBmbaPRtkbNW2+qmS1l2?=
 =?us-ascii?Q?NYPr3hS+yXF9YRGhIamL10ctw4YMZLUkbSlbaygpVk8Pased5Kq2W8RNcnMu?=
 =?us-ascii?Q?nNrRFkSjaxRBA9Fo6YOpjpZz?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b75d04d5-106b-4f87-f088-08d989bf0193
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2021 18:19:30.9589
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ffdwjLMhQM+dFW9zuPxIyTtE1HUN8T111npSng6K8GY0wrk4HY+DJQVQJLXwPDcFqyjjLgAILjWcfOiNFU4MWg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2552
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10130 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 adultscore=0
 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001
 definitions=main-2110070118
X-Proofpoint-ORIG-GUID: 28ygwXWai5zKyPXbwTSjpx0nsyIDvPU1
X-Proofpoint-GUID: 28ygwXWai5zKyPXbwTSjpx0nsyIDvPU1
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

The concurrent use of multiple hugetlb page sizes on a single system
is becoming more common.  One of the reasons is better TLB support for
gigantic page sizes on x86 hardware.  In addition, hugetlb pages are
being used to back VMs in hosting environments.

When using hugetlb pages to back VMs, it is often desirable to
preallocate hugetlb pools.  This avoids the delay and uncertainty of
allocating hugetlb pages at VM startup.  In addition, preallocating
huge pages minimizes the issue of memory fragmentation that increases
the longer the system is up and running.

In such environments, a combination of larger and smaller hugetlb pages
are preallocated in anticipation of backing VMs of various sizes.  Over
time, the preallocated pool of smaller hugetlb pages may become
depleted while larger hugetlb pages still remain.  In such situations,
it is desirable to convert larger hugetlb pages to smaller hugetlb pages.

Converting larger to smaller hugetlb pages can be accomplished today by
first freeing the larger page to the buddy allocator and then allocating
the smaller pages.  For example, to convert 50 GB pages on x86:
gb_pages=`cat .../hugepages-1048576kB/nr_hugepages`
m2_pages=`cat .../hugepages-2048kB/nr_hugepages`
echo $(($gb_pages - 50)) > .../hugepages-1048576kB/nr_hugepages
echo $(($m2_pages + 25600)) > .../hugepages-2048kB/nr_hugepages

On an idle system this operation is fairly reliable and results are as
expected.  The number of 2MB pages is increased as expected and the time
of the operation is a second or two.

However, when there is activity on the system the following issues
arise:
1) This process can take quite some time, especially if allocation of
   the smaller pages is not immediate and requires migration/compaction.
2) There is no guarantee that the total size of smaller pages allocated
   will match the size of the larger page which was freed.  This is
   because the area freed by the larger page could quickly be
   fragmented.
In a test environment with a load that continually fills the page cache
with clean pages, results such as the following can be observed:

Unexpected number of 2MB pages allocated: Expected 25600, have 19944
real    0m42.092s
user    0m0.008s
sys     0m41.467s

To address these issues, introduce the concept of hugetlb page demotion.
Demotion provides a means of 'in place' splitting of a hugetlb page to
pages of a smaller size.  This avoids freeing pages to buddy and then
trying to allocate from buddy.

Page demotion is controlled via sysfs files that reside in the per-hugetlb
page size and per node directories.
- demote_size   Target page size for demotion, a smaller huge page size.
		File can be written to chose a smaller huge page size if
		multiple are available.
- demote        Writable number of hugetlb pages to be demoted

To demote 50 GB huge pages, one would:
cat .../hugepages-1048576kB/free_hugepages   /* optional, verify free pages */
cat .../hugepages-1048576kB/demote_size      /* optional, verify target size */
echo 50 > .../hugepages-1048576kB/demote

Only hugetlb pages which are free at the time of the request can be demoted.
Demotion does not add to the complexity of surplus pages and honors reserved
huge pages.  Therefore, when a value is written to the sysfs demote file,
that value is only the maximum number of pages which will be demoted.  It
is possible fewer will actually be demoted.  The recently introduced
per-hstate mutex is used to synchronize demote operations with other
operations that modify hugetlb pools.

Real world use cases
--------------------
The above scenario describes a real world use case where hugetlb pages are
used to back VMs on x86.  Both issues of long allocation times and not
necessarily getting the expected number of smaller huge pages after a free
and allocate cycle have been experienced.  The occurrence of these issues
is dependent on other activity within the host and can not be predicted.

v3 -> v4
  - Fix dead store in demote_size_show and rewrite to look better
  - Fix documentation typo
  - Make code setting up per-hstate demote orders more clear
  - Add warning if demote_pool_huge_page passed null demote order
  - Acquired hugetlb_lock lock later in demote_store
  - Restored cma_release debug message
  - Updated commit message for the need of using HUGETLB_PAGE_ORDER
  - Renamed function to destroy hugetlb pages for demote
  - Made sure error codes are passed all the way back to user

v2 -> v3
  - Require gigantic_page_runtime_supported for demote
  - Simplify code in demote_store and update comment
  - Remove hugetlb specific cma flag, add cma_pages_valid interface
  - Retain error return code in demote_free_huge_page

RESEND -> v2
  - Removed optimizations for vmemmap optimized pages
  - Make demote_size writable
  - Removed demote interfaces for smallest huge page size
  - Updated documentation and commit messages
  - Fixed build break for !CONFIG_ARCH_HAS_GIGANTIC_PAGE

v1 -> RESEND
  - Rebase on next-20210816
  - Fix a few typos in commit messages
RFC -> v1
  - Provides basic support for vmemmap optimized pages
  - Takes speculative page references into account
  - Updated Documentation file
  - Added optimizations for vmemmap optimized pages

Mike Kravetz (5):
  hugetlb: add demote hugetlb page sysfs interfaces
  mm/cma: add cma_pages_valid to determine if pages are in CMA
  hugetlb: be sure to free demoted CMA pages to CMA
  hugetlb: add demote bool to gigantic page routines
  hugetlb: add hugetlb demote page support

 Documentation/admin-guide/mm/hugetlbpage.rst |  30 +-
 include/linux/cma.h                          |   1 +
 include/linux/hugetlb.h                      |   1 +
 mm/cma.c                                     |  24 +-
 mm/hugetlb.c                                 | 318 ++++++++++++++++++-
 5 files changed, 353 insertions(+), 21 deletions(-)

-- 
2.31.1