From patchwork Wed Apr 12 19:59:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pasha Tatashin X-Patchwork-Id: 13209487 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 9A887C77B73 for ; Wed, 12 Apr 2023 19:59:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21850900003; Wed, 12 Apr 2023 15:59:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C8A0900002; Wed, 12 Apr 2023 15:59:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0909B900003; Wed, 12 Apr 2023 15:59:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ED7F6900002 for ; Wed, 12 Apr 2023 15:59:44 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AC597A017A for ; Wed, 12 Apr 2023 19:59:44 +0000 (UTC) X-FDA: 80673804288.14.B35501F Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf21.hostedemail.com (Postfix) with ESMTP id 0DBD01C0007 for ; Wed, 12 Apr 2023 19:59:42 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=YhLpdi3+; spf=pass (imf21.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681329583; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=dw+CWACRZsXFxLftto9WrsOlG3O76TJuQrKX+zvFATY=; b=4Rh4h2zn4iXGhh5zxgbpLckYegVMpqv2rT/eEgKSKhxwqrszEsSLN/g8+4X3nEUVWcPSSA Z4ZIaLfHmdLP+T28Bcc2fGektomj7qcobg8NLBv0eKe/InF74BF7uyOCiqyBb9RTxF8V66 fI5tXuXNZkE1vIxEuf0UAHT5Uujljpo= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=YhLpdi3+; spf=pass (imf21.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681329583; a=rsa-sha256; cv=none; b=UdhQMm1xIdwNADZGU1OwJ9XE9EAaJGQXsTv3oWnwd7F2YsTZkgKBWyKiSVEIHEHzwdB+Td tcFdL7DvG68rS76/G/7aQHWlur0jXdjJ2RpafPKKc/ccRKOVVhlyL49DKTi3Ucu5KOcse+ NAR5maE5q3J6cGIatpnmsSQ6KyY7tuU= Received: by mail-qt1-f175.google.com with SMTP id e3so1198646qtm.12 for ; Wed, 12 Apr 2023 12:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1681329582; x=1683921582; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=dw+CWACRZsXFxLftto9WrsOlG3O76TJuQrKX+zvFATY=; b=YhLpdi3+0jUzIX1YuB+r9CraTavpImPkjyW8na7sQw8iNCJwZl8oL881pRmVX0cWm8 yPW/G4zD+mb7ZWuLNbxaUHOvF6HRo9w4bxK1LwexUXFwpPGP4DNy3qbPBr9pj4mIJKYO vmapX99d5UskrdNAovMELRusPJkxLffPBgH8qK2zf5PeNE1rHGq7D6MTa8/C/WDz+6WT AnbhfZDe3k2Zju5D0ZIGweRTDGlnfgx3zKngCNOKBF6TdU9jziAok0yszwgEnatOfPoB veUNzaTSW2uto4cRdHotqCb/ek7Zl9+pVNDkRBUAtGXnIzC9wUjQ6MU2Zzm6xZ4nxcOL 0/GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681329582; x=1683921582; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dw+CWACRZsXFxLftto9WrsOlG3O76TJuQrKX+zvFATY=; b=WApqWhRQsDp3Kbjgp8rUX6WC6MTuzNXLhNnxyGSkNJ5dsY0TIW8aAdffRW8m2m0bPX EnBnp7Fsmrnaq0kOUJYdWOD3d95Dw7GF2anW5kVJ3IKHMiGbuQeTnHTp6xQESwlIhFqb e3qJkwQ/al+JQ710rO2Fw7vLjl18yuoarEnZAReKPxVqS+7Hrf+OHze7Q3vclxmqJ8Zx o8GfEURzeaL3l9tuY0NRL81qCB/oxmzjNeDTup+zhjUcT1xlSwuvYM1T/05XoppVW4ll 2jG9npSETKF6X3bcJfa4fa3rj8KktkO7Dai6l8fEuniCelFd7CvMUlY3wFfPxvNXg6hM 0YuQ== X-Gm-Message-State: AAQBX9dwhY+iYZ874ICj3Um3sR7WOK8avcJrZIbkIvshNj2QNKO3uElI Km5+oP6ogUKsxJrA7StdQZLOX4nN+Ocm/W4jNw8= X-Google-Smtp-Source: AKy350ZBZ7+QxyO70G0a3OfH9O3pPgV5amEiB4UezT5PCbHingEGJ338rE0MSo148xObrYKclTI3qw== X-Received: by 2002:a05:622a:1102:b0:3e2:3ae2:790e with SMTP id e2-20020a05622a110200b003e23ae2790emr24712205qty.32.1681329582240; Wed, 12 Apr 2023 12:59:42 -0700 (PDT) Received: from soleen.c.googlers.com.com (193.132.150.34.bc.googleusercontent.com. [34.150.132.193]) by smtp.gmail.com with ESMTPSA id do28-20020a05620a2b1c00b007484bc04a63sm4896504qkb.99.2023.04.12.12.59.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Apr 2023 12:59:41 -0700 (PDT) From: Pasha Tatashin To: pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, mike.kravetz@oracle.com, mhocko@suse.com, muchun.song@linux.dev, rientjes@google.com, souravpanda@google.com Subject: [PATCH v2] mm: hugetlb_vmemmap: provide stronger vmemmap allocation guarantees Date: Wed, 12 Apr 2023 19:59:39 +0000 Message-Id: <20230412195939.1242462-1-pasha.tatashin@soleen.com> X-Mailer: git-send-email 2.40.0.577.gac1e443424-goog MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: qz9eaxtq1aszndj8nyoq6hcsrxjwnmn4 X-Rspamd-Queue-Id: 0DBD01C0007 X-HE-Tag: 1681329582-457900 X-HE-Meta: U2FsdGVkX1+otWUg0QgBuhZPIF6FkH55e+BaFTqVMSSsa0CilUNn0ENIsYew0fSLWa0x8wtpIDFCWDovpr5gmae2Y2FPSizMJL8mCVYNt5vhpKNxzSrsMJ0G8TKcRs79tkFlC4uiB9vNBMePdKRoq6YcOnb0Kv47hOKkXJjZdP4HYdk19shnElxoL1CcF7zck6uaoBDTCTdHJThS6VweziX9C7dEI+2qb43RV/Q97p73asD6a/S9CY+dXLi4bDa3YZtpR7xeEFSBlon6GZcXU8r2xnOvcTcFU8eAUJYHzpiZvPD0eQJ6oz/cfM8YHGFC40LujDQEApGpEIdDHtEwCitU1E7zVhXBvb93lK3C5hEO6PdoPwBaD1zZ2nqM7h54jSxtbi/QiVRJBYebmzYWZby9oKJTHAbQpgzmZ2r1eOSrLbjTFm30Lg7B9aDeCjENl9QGZ++j0bmnh1xuWZxwNJLrq3EDJpAJkAdfPWHHj3vbDXSrqyYTXVjxyrENyTqIwzzTV/fwYcegOZD8VH6YrgBJOlJTUEjN6+qxorPRaEKSzm1qfXeJbONsGbEZgsQ6AX2EiYGtsZnwc5KvLMK+m4KMdkXU02e85QRsSGByx0j3ROzqdRsdoiF/XRkp6gZZnVzELywyse9hjhZiUElI5tPD8//DdtGr/TTk1kYUZl24LRJLG/8E+40rdPBpkV77jdW1L+gugJXyw+Ia3kWq9aaNZPC3jWLhHW1tdupKot4M/JBVmjES75rKevigCYW7H3pIg4bEVhff1XBB6d9mswkNldmTqGBTK/uPr9661fa6MjsrWijInVZ+LYc9alBySHecNqEVM4vu1gPTFz2e5tSXPU5E5hTbP9JTXR8DtwQ6eOc+WwaVoZfv99qtDR/a57mVtk0fhWHNClnGwM5pgAC9b9/0mSWyRywYb/QeGqqFTn2AXiri6vikeD4ZxLi3ZtKqeu4GVC8pgHb8Llu VCrAnd6k lNBnDxJm21TbrQ8h/BmxxtBKApTYb+ltGK0VIBQWkfx2NwhtSrFLoPkJJgC/UBBNfjJRvxwxVIY1LiCUwJYGXltNBXbxR4H0/buDpNZLBpD2Igf+/5A4NazTUeZme5kMv87IjfEVsl/3RpuL8cN+2fznFVsLQ9CTSFFY+TrJzArZcV3XkOnzm4uQjkRppV8IOrGfozq87TQZPFS2XBKwrOqHAT7V7hou56t8wGNfilZdFfsxvUquV3w89qe1Zs3qTytDJNw01lzIjvs+UANQKp6WC0X1TSJmMLJZqMUS6BnaLLzPgcmw3MWR23njLbUPohpzRD0VH033jgd3Yo4b4v78ZPlgnjiLLFr6Lpo63wnFC6BXNs4+HGLnH/RWzMpU2m3kuhEd53denWByD3H4c3E21PM0HegGBGNV2vh00vmKms3HhS7tgF+ogTwiNY/QwnA3HTe4JTuXRUcQ= 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: HugeTLB pages have a struct page optimizations where struct pages for tail pages are freed. However, when HugeTLB pages are destroyed, the memory for struct pages (vmemmap) need to be allocated again. Currently, __GFP_NORETRY flag is used to allocate the memory for vmemmap, but given that this flag makes very little effort to actually reclaim memory the returning of huge pages back to the system can be problem. Lets use __GFP_RETRY_MAYFAIL instead. This flag is also performs graceful reclaim without causing ooms, but at least it may perform a few retries, and will fail only when there is genuinely little amount of unused memory in the system. Signed-off-by: Pasha Tatashin Suggested-by: David Rientjes --- mm/hugetlb_vmemmap.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) Changelog: v2 - removed gfp_mask argument from alloc_vmemmap_page_list as suggested by David Rientjes. - Fixed spelling in the patch title. diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index a559037cce00..236647e4bfec 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -384,8 +384,9 @@ static int vmemmap_remap_free(unsigned long start, unsigned long end, } static int alloc_vmemmap_page_list(unsigned long start, unsigned long end, - gfp_t gfp_mask, struct list_head *list) + struct list_head *list) { + gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_THISNODE; unsigned long nr_pages = (end - start) >> PAGE_SHIFT; int nid = page_to_nid((struct page *)start); struct page *page, *next; @@ -413,12 +414,11 @@ static int alloc_vmemmap_page_list(unsigned long start, unsigned long end, * @end: end address of the vmemmap virtual address range that we want to * remap. * @reuse: reuse address. - * @gfp_mask: GFP flag for allocating vmemmap pages. * * Return: %0 on success, negative error code otherwise. */ static int vmemmap_remap_alloc(unsigned long start, unsigned long end, - unsigned long reuse, gfp_t gfp_mask) + unsigned long reuse) { LIST_HEAD(vmemmap_pages); struct vmemmap_remap_walk walk = { @@ -430,7 +430,7 @@ static int vmemmap_remap_alloc(unsigned long start, unsigned long end, /* See the comment in the vmemmap_remap_free(). */ BUG_ON(start - reuse != PAGE_SIZE); - if (alloc_vmemmap_page_list(start, end, gfp_mask, &vmemmap_pages)) + if (alloc_vmemmap_page_list(start, end, &vmemmap_pages)) return -ENOMEM; mmap_read_lock(&init_mm); @@ -476,8 +476,7 @@ int hugetlb_vmemmap_restore(const struct hstate *h, struct page *head) * When a HugeTLB page is freed to the buddy allocator, previously * discarded vmemmap pages must be allocated and remapping. */ - ret = vmemmap_remap_alloc(vmemmap_start, vmemmap_end, vmemmap_reuse, - GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE); + ret = vmemmap_remap_alloc(vmemmap_start, vmemmap_end, vmemmap_reuse); if (!ret) { ClearHPageVmemmapOptimized(head); static_branch_dec(&hugetlb_optimize_vmemmap_key);