From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93CD3EE14D3 for ; Thu, 7 Sep 2023 06:20:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AD478E0018; Thu, 7 Sep 2023 02:20:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85D078E000F; Thu, 7 Sep 2023 02:20:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74D228E0018; Thu, 7 Sep 2023 02:20:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 670368E000F for ; Thu, 7 Sep 2023 02:20:33 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 297B81CAE34 for ; Thu, 7 Sep 2023 06:20:33 +0000 (UTC) X-FDA: 81208802346.26.42EDD8A Received: from out-214.mta0.migadu.com (out-214.mta0.migadu.com [91.218.175.214]) by imf25.hostedemail.com (Postfix) with ESMTP id 327C3A0016 for ; Thu, 7 Sep 2023 06:20:30 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nEPh6ulc; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.214 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694067631; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/F7h9TiNNa7lrbVKcJMgQDBJdRxF3UEGbRAi+uX3qX4=; b=YvzQwZHGLpOJuJaLfWA/aI8hrUIIfYlK1RkQbabCuJc5X3XjUmzmRXiQz4zM6PpWD590/k F6AfDKhmDqlfvdcUc76duRAPVjjzoGVySLjHc76fLJkIFATL1+jzzUdsHJjU2qeuLhLM3g fX3MvPZquMCmsk8nvvNwtphn7KViJJk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=nEPh6ulc; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.214 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694067631; a=rsa-sha256; cv=none; b=MVzSKenDtYKT+r8HH5Sz1jy23W0LD9KguQ5bLe6EwNf181firQcSgyAq+zL/fgvqCACAhB iccqlbcKFzTdGLN28g9kVlsLmznooZUE/DSy31EPeG25kHDPPprea1RiTUQWraSurr+dw5 mhpL4+SL0VY3CyrrJBWD5iNhFvAiWKw= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1694067629; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/F7h9TiNNa7lrbVKcJMgQDBJdRxF3UEGbRAi+uX3qX4=; b=nEPh6ulcfFBu6ATTQcm5TTFdu2fIloClDLDU9Ug//uYrL448O/rda4rgK6bUZ7nY9XM+MK rdD1nHgwFT+BnaJSNrmW5M8LHpsF0K3pxLTm4yj8vWjUDlw78KzosrMnsjRKmLE153Ab4v iTzNOj+aND5yigiJuQK7YFHqMA/xX+Y= Mime-Version: 1.0 Subject: Re: [PATCH v2 08/11] hugetlb: batch freeing of vmemmap pages X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230906213855.GD3612@monkey> Date: Thu, 7 Sep 2023 14:19:45 +0800 Cc: Linux-MM , LKML , Muchun Song , Joao Martins , Oscar Salvador , David Hildenbrand , Miaohe Lin , David Rientjes , Anshuman Khandual , Naoya Horiguchi , Michal Hocko , Matthew Wilcox , Xiongchun Duan , Andrew Morton Content-Transfer-Encoding: quoted-printable Message-Id: <9F499C49-3046-4EF2-8C2A-3458A954B2DE@linux.dev> References: <20230905214412.89152-1-mike.kravetz@oracle.com> <20230905214412.89152-9-mike.kravetz@oracle.com> <20230906213855.GD3612@monkey> To: Mike Kravetz X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 327C3A0016 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: kmenjx8e6hifohbf7pxrbb5j9epyaobg X-HE-Tag: 1694067630-888216 X-HE-Meta: U2FsdGVkX1+cQd8x1qKM7pKbDFuu7voDmdEsNQ6WMHOhXDGZMAjn4XTzQdZpHGbBu4TdCqr5P5jrRXKKpXxdldiATiK9GVnQMQ6erTtxzTrAXmawDUFhwrpQy5Ju6a3/OE0B3oTJvqfRXw4LilpsCGMdwfzjQAn3VxfwpkKKtmrvTpwgXoA1oNRfcU2Tf0khsSg10Ql1AJKJX0nZ9SF5wXVsmpC9Ff0vAcGT9APxutmJAWW0ZohgLzkixrXgSuSC5en+1uVNReDq5pmMh6eOoJHI2Ofs4Qv9eE7vDKTbCuGpNi/OeOdr9MSsiXk3m2WJTyOTtmy05mDkhX4xAX9HOfaKerkZttVtp9zI/9i/KP3zzb3qAqk5LmXnyN8QWyy16OsD4g8AEyyDomNdOrMn53VYvjzIeBPGwOt98zc3c2MwKX55KJRS8rjOaaU08h8vU61v5Nj/sOEburbhoesC1vpgKd9AsPUCT9UTHrRaAh1hhE92sAhCgwbMrPhmVb3cmnDLpLOLbi8BjyswZrafJ1hDPTyuvtYUXMOzLhzp1ku0EgfWDHd4cs35ixgl5r+yvjr+H73+c7REuaQpag8VWzarVuR+DbJ4wd6oICKvGNTbDVF1V+nIdm0i1AVshq3zUjNOKGDusG0rx6CMzb+nN2t0jHsPdpo2UuOTZEbKpIlyarjk3dGRdS5nPxRkoz6jKesGj36Q/S4Se9ELXj/iv4SXl4gAyUVoLMtr+bOsMxwzp2jRJQJzxibMYgFiG3N4BiAbRx7hlpzlMSPFk9BeElRFp0GPwNmH/3MqTHsDsHXIQia8wUa+4ox7uGx23V6yb0AdIk81JMfBFi1H7MfHzZ2cu9kVDjcHtq6Z1pG1cl6aH3yyowWx1vhuUDO0DGH8/mAMkOCOwd8Hc7FvkPDqitwp0qqoJqN1iSupVmFfT0xLIutd+tU38kpFW0z5kfJgGOEYxzo2gLXsGu/KarG 6nCCMKzd 5OW6SPpKMkhdsmihhS8EYutVexNDL2t6q1A9xxmFa1qviWlLyQd8XKiv7zcpW63kLPoKZgpm+bUvOLBz3xJcp6JPWGVCleq7AKiXU+85P9C/3YnDQmVAi6LcEEcMoiWxz88YGHACe+mF7zzk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Sep 7, 2023, at 05:38, Mike Kravetz = wrote: >=20 > On 09/06/23 15:38, Muchun Song wrote: >>=20 >>=20 >> On 2023/9/6 05:44, Mike Kravetz wrote: >>> Now that batching of hugetlb vmemmap optimization processing is = possible, >>> batch the freeing of vmemmap pages. When freeing vmemmap pages for = a >>> hugetlb page, we add them to a list that is freed after the entire = batch >>> has been processed. >>>=20 >>> This enhances the ability to return contiguous ranges of memory to = the >>> low level allocators. >>>=20 >>> Signed-off-by: Mike Kravetz >>> --- >>> mm/hugetlb_vmemmap.c | 60 = ++++++++++++++++++++++++++++---------------- >>> 1 file changed, 38 insertions(+), 22 deletions(-) >>>=20 >>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c >>> index 79de984919ef..a715712df831 100644 >>> --- a/mm/hugetlb_vmemmap.c >>> +++ b/mm/hugetlb_vmemmap.c >>> @@ -306,18 +306,21 @@ static void vmemmap_restore_pte(pte_t *pte, = unsigned long addr, >>> * @end: end address of the vmemmap virtual address range that we = want to >>> * remap. >>> * @reuse: reuse address. >>> + * @vmemmap_pages: list to deposit vmemmap pages to be freed. It = is callers >>> + * responsibility to free pages. >>> * >>> * Return: %0 on success, negative error code otherwise. >>> */ >>> static int vmemmap_remap_free(unsigned long start, unsigned long = end, >>> - unsigned long reuse) >>> + unsigned long reuse, >>> + struct list_head *vmemmap_pages) >>> { >>> int ret; >>> - LIST_HEAD(vmemmap_pages); >>> + LIST_HEAD(freed_pages); >>=20 >> IIUC, we could reuse the parameter of @vmemmap_pages directly instead = of >> a temporary variable, could it be dropped? >>=20 >=20 > I was concerned about the error case where we call vmemmap_remap_range = a > second time. In the first call to vmemmap_remap_range with = vmemmap_remap_pte, > vmemmap pages to be freed are added to the end of the list = (list_add_tail). > In the call to vmemmap_remap_range after error with = vmemmap_restore_pte, > pages are taken off the head of the list (list_first_entry). So, it = seems > that it would be possible to use a different set of pages in the = restore Yes. > operation. This would be an issue if pages had different = characteristics such > as being on different nodes. Is that a real concern? A good point. Now I see your concern, it is better to keep the same node as before when error occurs. >=20 > I suppose we could change vmemmap_remap_pte to add pages to the head = of > the list? I do not recall the reasoning behind adding to tail. I think we could do this, the code will be a little simple. Actually, = there is no reason behind adding to tail (BTW, the first commit is introduced = by me, no secret here :-)). Thanks. > --=20 > Mike Kravetz