Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 22 Sep 2022 13:25:51 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Doug Berger <opendmb@gmail.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Muchun Song <songmuchun@bytedance.com>,
        Oscar Salvador <osalvador@suse.de>,
        Michal Hocko <mhocko@suse.com>,
        David Hildenbrand <david@redhat.com>,
        Florian Fainelli <f.fainelli@gmail.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] mm/hugetlb: hugepage migration enhancements
Message-ID: <YyzEz4snl2x51iTY@monkey>
References: <20220921223639.1152392-1-opendmb@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220921223639.1152392-1-opendmb@gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6SZfxiFmCvwIThzQcCHMvApWVxETatxOsT7PHu3e4PwZF1o2S9KWFi01OI1N?=
 =?us-ascii?Q?Q7SpS/sbdcgGBpf7fz8a6bm6Dd1cjp6DhiRTlno3GaZvIdyEBQ48bJxEBFYd?=
 =?us-ascii?Q?iHQzS+sQbnhn1nVKfGN9fa0P+gxq690u8IjZlrvsfC6JgEcVtYHRuYnpZV2W?=
 =?us-ascii?Q?KguD2zFAtHDZMWBBqS/c9GWKqH21qI7cH2q/yG1P+ZTWyoNZJAbdIlZeXPtN?=
 =?us-ascii?Q?Y78H3VFMj2bpzMv8C+vSu4Vcsbz8X5RjhNWTWJwGosPl3KMhp3QsmjZi3D+J?=
 =?us-ascii?Q?a5m47+3fn6rF2feuAPWf194yu54yzPqhN86AU/wfmj14KDN2tqDmfrasbqNm?=
 =?us-ascii?Q?l6Mf0IF+7mF7ft9mZTWTRi3ie01v5r3rRQQ6yv7tXM6rCDj8nUtZnQhe6liR?=
 =?us-ascii?Q?R691v4TBrKQPYq8DoBoy4+rXctJ5fCji1EFe1WxfAxAonyz8A2WuCd4I86zo?=
 =?us-ascii?Q?DxOOEkmqkCV7+7tLSjEPmi5iwj8nSivcjAKU+noM0NIX6UPenN2qeIFfsTFk?=
 =?us-ascii?Q?efl8dQUHGEfkFBnacx0S2ihUpXYdWO+AzZZKJfWJnlq3+brZCwluFG1MtVS4?=
 =?us-ascii?Q?Qrpq/6bvgwFzoLuL3oCqwAU1hdi6yI/7YE/1zTiMbDf7bXcIk7r+VOikf3sK?=
 =?us-ascii?Q?weQSdNbDWMBrZWTa8Ykejr/cK80weN7HuTTDN/a8vDz33PEnSvthCGACUmLd?=
 =?us-ascii?Q?uQ6i5Yz5T8eBUsy6NGnkq7dUIg6jkD7mzINaHoc5jH/PGDYwAnR1S8BDMD8e?=
 =?us-ascii?Q?D2IZ8ILj3N2VVz5U3g+erXBrNuIu2TdnS+zBhj22EHm1S1awd5t4uZ8hCak3?=
 =?us-ascii?Q?+YHzzSUKUCKOXCYtO/VdWnt6wT5NRDEjkjrr/8/xmzCe6ueyuVd0ieZ4ZKho?=
 =?us-ascii?Q?rrER4r7e3yzKUUgvXs41+YJFIZcA9WnA5TaOzZWogW09D9cmc0RjzBpGkV6v?=
 =?us-ascii?Q?v+g6O7BB/GO8i/OmeEP33lBrUmYqRA+vtupuqX1xbhUnr633jD1ae8Jvyupr?=
 =?us-ascii?Q?qrnBDT0evR9/4hZEDgHYCJQGBZUCQ8RBsHHYzn9vW8sDjNzCK0IKtz56wu3K?=
 =?us-ascii?Q?VXc9soznHXqnCCtaJdoEEnE3PsMCTrRj372FffFYAWaE5ntUhjM7SfzfMT0S?=
 =?us-ascii?Q?R6rqvjx8uDv9Wx+wjnbV/jEIaJ2ZKQuJykU5Gg5ITObJ/uYH4yfI6eoq1SW3?=
 =?us-ascii?Q?JhpI2PyJ9ii7SioJ+YXVRTyb6zaf2UKbNNsjh1Mnr8GFe6FCAonktfGTkyNG?=
 =?us-ascii?Q?RNqfsOzxE2iTVzfk+y26Xro8a8BJT6DU7k5ueRmqLxgY4XM9sp4V4a6U6U3i?=
 =?us-ascii?Q?dOnV58Z1HewHi8f0CILTr3qFzA9v9EdBPpdckK/AH6eicxptEyNGfLJTixZX?=
 =?us-ascii?Q?dvwB5CQ+sVPPeJRT4gu/g5LVtiJlfYU8nzHf66SambSTZq/7fNl0oEleHWsu?=
 =?us-ascii?Q?bc4qQ2FhfJsR49eFHZXV5T+SA3HdjdYWD0gfIjukEpwCeS6hIDL2oEq45Jbd?=
 =?us-ascii?Q?h/9Mz1oe1N5eu4JBcBqlpKOGSJ4aK+cXH1G7z6ZLfkccux0iYgtP/vn/FRuW?=
 =?us-ascii?Q?AT1KiKg7npuYxOqb++YdBZz6Wx6VrOiiOSF0Ro821CMtQQDtbyE+wvCOku+B?=
 =?us-ascii?Q?aw=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f41ae12f-0bfd-4dca-3f41-08da9cd8a5d9
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2022 20:25:53.7255
 (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: pWfAcgnyKP5bAjEQyFRXpWEzAqUSD7YETYDP2Q3/KARGdVVwc9iXuO6w3yJiO/4DnylXjKD7UM0A9dAfFABY8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB6838
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-22_14,2022-09-22_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=680
 spamscore=0 adultscore=0 mlxscore=0 malwarescore=0 bulkscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2209220131
X-Proofpoint-ORIG-GUID: 0Dkdy6tC9FVmRMx0OFW1wxVNjTvDBI3o
X-Proofpoint-GUID: 0Dkdy6tC9FVmRMx0OFW1wxVNjTvDBI3o
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/21/22 15:36, Doug Berger wrote:
> This patch set was included as patches [04/21-06/21] in my
> previous patch set to introduce Designated Movable Blocks [1].
> They were included there for context, but they have value on
> their own and are being resubmitted here for consideration on
> their own merits.
> 
> The alloc_contig_range() function attempts to isolate the free
> pages within the range and migrate the data from non-free pages
> within the range to allow those pages to become isolated free
> pages. If all of the pages in the range are on isolated free
> page lists they can be allocated to the caller.
> 
> When free hugepages are encountered in the range an attempt is
> made to allocate a new compound page to become a replacement
> hugepage and to dissolve the free hugepage so that its pages
> within isolated pageblocks can be added to the isolated free
> page lists. Hugepages that are not free and encountered within
> the range must be migrated out of the range and dissolved to
> allow the underlying pages to be added to the isolated free
> page lists.
> 
> Moving the data from hugepages within the range and freeing the
> hugepages is not sufficient since the allocation of migration
> target hugepages is allowed to come from free hugepages that may
> contain isolated pageblocks and freed hugepages will not be on
> isolated free page lists so the alloc_contig_range() will fail.

Thanks for looking into this!  I am adding Oscar, Michal and David on
Cc: as they have looked at similar issues in the past.

Before jumping into the details of your changes, I just want to make one
observation.  When migrating (or dissolving) hugetlb pages that are in a
range operated on by alloc_contig_range(), we should not change the number
of hugetlb pages available as noted here.  This includes the number of
total huge pages and the number of huge pages on the node.  Therefore,
we should allocate another huge page from buddy either as the migration
target or to take the place of the dissolved page.

For free huge pages, we do this via alloc_and_dissolve_huge_page.  IIUC,
there are no issues with this code path?

As noted above, for pages to be migrated we first try to use an existing
free huge page as the target.  Quite some time ago, Michal added code to
allocate a new page from buddy as the target if no free huge pages were
available.  This change also included a special flag to dissolve the
source huge page when it is freed.  It seems like this is the exact
behavior we want here?  I wonder if it might be easier just to use this
existing code?
-- 
Mike Kravetz

> To address these shortcommings the HPG_dissolve hugepage flag is
> introduced to tag hugepages that must be dissolved when they are
> freed so that their underlying pages can be moved to the page
> allocator's free lists. This prevents hugepages that have had
> their data migrated to new hugepages from being made available
> to subsequent hugepage allocations and allows the isolated free
> page test of alloc_contig_range() to succeed.
> 
> Dissolved hugepages must be replaced with new hugepages to keep
> the hugetlbfs balanced. To support blocking allocation a new
> workqueue in introduced that is analogous to the workqueue
> introduced to support the hugetlb vmemmap optimization. This new
> workqueue allows the allocation and dissolution of the hugepage
> to be offloaded to a separate context from the freeing of the
> hugepage. The sync_hugetlb_dissolve() function is introduced to
> allow outstanding dissolution of hugepages to complete before
> the isolated free page check is made by alloc_contig_range().
> 
> In addition, a check is added to hugepage allocation to prevent
> free hugepages within an isolated pageblock range from being
> used to satisfy migration target allocations preventing circular
> migrations.
> 
> [1] https://lore.kernel.org/linux-mm/20220913195508.3511038-1-opendmb@gmail.com/
> 
> Doug Berger (3):
>   mm/hugetlb: refactor alloc_and_dissolve_huge_page
>   mm/hugetlb: allow migrated hugepage to dissolve when freed
>   mm/hugetlb: add hugepage isolation support
> 
>  include/linux/hugetlb.h |   5 ++
>  mm/hugetlb.c            | 161 +++++++++++++++++++++++++++++++---------
>  mm/migrate.c            |   1 +
>  mm/page_alloc.c         |   1 +
>  4 files changed, 131 insertions(+), 37 deletions(-)
> 
> 
> base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
> -- 
> 2.25.1
>