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 07DF7C77B6E for ; Wed, 12 Apr 2023 20:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B8D8900003; Wed, 12 Apr 2023 16:01:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96922900002; Wed, 12 Apr 2023 16:01:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85A50900003; Wed, 12 Apr 2023 16:01:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7452E900002 for ; Wed, 12 Apr 2023 16:01:31 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3C6A14022F for ; Wed, 12 Apr 2023 20:01:31 +0000 (UTC) X-FDA: 80673808782.08.47BCBE8 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf11.hostedemail.com (Postfix) with ESMTP id 31B284001C for ; Wed, 12 Apr 2023 20:01:29 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=kGXowdrE; dmarc=none; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681329689; 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=8o5q/MDP7b8EY8/uHOBhi/czXTo+bJcB+b/n0D+eyPs=; b=cQ3IHgFbzGoj/BVn8B1466+TxfB4C9FkSn7nijfN3nLMZmwWsGMQ06A/OTDu0S+Ojvc227 /beo6HZTCLyzwzVai+lIuuzmwRANfK1xE/3kioDfAXGLhTVtMOyI8QXDGsudUL7ESD+9pv VCJz2VIby/CE+RhQRR7vCAJ+bV2AVOE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=kGXowdrE; dmarc=none; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681329689; a=rsa-sha256; cv=none; b=1pYKESEf91WC/5EHU6VX9XkL0JvzWfiBVjs/hSh4KtItBjtQ45ryLCY3AFlXNScQ4cvX7E VmlhwIrLA1uxQaCWmvM2xu+POp+Q4tbT0Iu8/l675rxrC49jixECEIfVEGIMfvfSqr9k2S 1smgoaBDp/tvt3XurAPae36bHVsZEUc= Received: by mail-qt1-f176.google.com with SMTP id fv6so458911qtb.9 for ; Wed, 12 Apr 2023 13:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1681329688; x=1683921688; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8o5q/MDP7b8EY8/uHOBhi/czXTo+bJcB+b/n0D+eyPs=; b=kGXowdrE9W59nhkKnD88XHCg63cI/CqPa2scem6wKxFDpSAPt/BNBueuu7ShliBJ78 wxLCHq+TtYFXBSQNHs8Nv6yk2fcXvqWKV45kdGfURW5yA2mLVq7L51grs6e1JhRe4RSR ovfjg4HlZQbFX/Y1X/vnX6nzLvH8MlLAPaJkuBXRkJgprsOZe/nhTQpysj6MGhOvQlva Xzs4nxZYPvOYqD+gz41fEwTVvHXHS2CKtLnyVE1LGq9K0ae4/eu+ylrUAHPFASDuUrgK 9oYW0ByA68z0Rnf86QWJtLsVq69TJIdLdf2BRk1V7MJgy2r/yU/GzI6TCuN7uao4WLub rGhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681329688; x=1683921688; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8o5q/MDP7b8EY8/uHOBhi/czXTo+bJcB+b/n0D+eyPs=; b=So7qE+ck27OK19KlXVdEh6fwPGYAd5TPcii8OUzvctRe115L6GPjVn6+hhI5Wp7P+y wy7vhscvryzyUods1YjIzj37Va2zOFgR3Qp1MUIZNw0fC0oByT9J6A6s+gvKy1DFePqg RZYwk3VHcQ4qqsEQzoogx20C0JbO+In0W5RPGWUz9VaQ71MCNVos90qFzRV9QfgxmEYm bUZDGFXT5zYqSZzZJYacgyviqx+fg26/J+LJ9x0bKBtThxXMhFjwMgMQSwzCqx9RyJCN wHQeTPiHtZAxBP4Gp3nXM9u3ZPA2ed0W4McpO7WYdpsw6d4J9ELIlwkaMw1tAh5iGzHU I0Vg== X-Gm-Message-State: AAQBX9dz73m+qWg4FLKuIgA1g+Wq99pBQgtP5iR82yvk7gl+oA9AJhCQ 9+lShc03wrxl4xm4S6yyewNkGXmB1nzMOrEWH3ROig== X-Google-Smtp-Source: AKy350aJ2bGrBAa+qz/GVnNDct6ZDcVSq7qR/7xS3x1LoUoCQczyFrcqsBPZR9REagIaXCeiFX+vDzCHUPX5OaLJ5hc= X-Received: by 2002:a05:622a:1815:b0:3df:4392:1aff with SMTP id t21-20020a05622a181500b003df43921affmr2603706qtc.6.1681329688375; Wed, 12 Apr 2023 13:01:28 -0700 (PDT) MIME-Version: 1.0 References: <20230412152337.1203254-1-pasha.tatashin@soleen.com> <63736432-5cef-f67c-c809-cc19b236a7f4@google.com> <20230412195723.GA4759@monkey> In-Reply-To: <20230412195723.GA4759@monkey> From: Pasha Tatashin Date: Wed, 12 Apr 2023 16:00:52 -0400 Message-ID: Subject: Re: [PATCH] mm: hugetlb_vmemmap: provide stronger vmemmap allocaction gurantees To: Mike Kravetz Cc: David Rientjes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, muchun.song@linux.dev, souravpanda@google.com, Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 31B284001C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: aejgadp6ftiabdt7crdei8casfgzxbj7 X-HE-Tag: 1681329689-921891 X-HE-Meta: U2FsdGVkX19gjiW0cD8h0FcSMMJpaamkSFF7Ziekm2tR7x5yHN9pEgXSv6TA4i7KFNbpEbmindqzixG/6FlcXda24Et3CEc6d2pMvVklSHj0RGP6sy96fF41sj0zsAnd0FVTLRUM5TYaB4/kSNnUebf2Nqf6bRM6Id5xw22oKQPhCduJgHtOPu5pfL/fkP2ez4zeAQK+XAYzoAhdRPiXMQYOXN/ShDpJXZaoRJ0zkQDLxoCd5nQ9qNcvGJsKI/11CVNK70jsBfrIKNgdzprgo+9njQsGT1qVZ+2CKCmRgy+MVVJVqe5tvIOB+1Q8vaGWpxtboMHMVlQ102rl3IMvK+kliLjJKx/O1f57kkuP9CwafPlluY/FS9194EXQuFyMA8Znn1L8nBKYV2h5+cJxPmXYxgkaiwomn+j13d7GZCyyBpyZa0SEts3oZ2zcOo/mA1be+AptPDfZhuro1qHfEuXyOGYPQXLSUH/WI8cDmCSJGob+t1uhHhLz9foo1tEw6Gy3eltVFZCEnPWKEZw3OI5We8HUwQz6RGxT8+JV8Vqtu+J5RqcrkS+s50HfWhnKvzTgBmQTh4q33Rpdh09J1kOU63+c2vzf8GXgRD5OQSXMb4cA5X/IoREg7+CzA0YAfEMYyF50bXIxMU5I5hBxLtmyY7yZAFLZg6PXHx8k1tZ08l30zUeerP0IIFKiGRo4MWHAOAg3FXhJHPzEiWBTbajfUi2f3WqQFxry4as/8N+Wgu36A1cr/90UH1Nw6OOzzkOhBmH8OCYVoAcEjN0PQ6TmQM0TOUKOPnZ7uOSNtc4J5V8pkSNyN6ZeE1M5sZiX3r5BnrOhvP9tpKJQBGoxTGjXjmzlH5wNPp8q/FiL7Ja/QbVERCmSC59ZvSY356CStC2t3zey8t9kYvLa+oIwkYodcf+vu98/l15Y0SpA5PQabajl5tzp4akvOralgC9ZmAbUlvLup2pFNoe9qxu 3gh0gUxb diOLUhWXCWCpGs7rT0V7eNCcEOkkATfeu11Af0BYNhaHKUDG+yJzq6LRJZLtpbpauL14AwsLEyEWcfqP6B4p/+B+DeQC0y1l37MO0K+LuMM1reLUrAkB/uiZhcUGl33xSAu3IMNGhYyjJWZvJnko6vvw8hS5wfnBq5DZ5sQgNOfRTs4QYMp/eAzlngmSGKySzkekPewECylg/jXbC466uFQmKIBvdpJu7DkEbmwAZeT/EOsXng7J8n4KT7wny3YmDIKmcsACgagY8NlyPUwYxIdiqqq4tuo12uLsurrmBPs8PLvOLxGUSA/xH/sbM++GhmRZvo1acngsQi16l9SvoTFWqU/ttVgO8TEJ5 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 Wed, Apr 12, 2023 at 3:57=E2=80=AFPM Mike Kravetz wrote: > > On 04/12/23 10:54, David Rientjes wrote: > > On Wed, 12 Apr 2023, Pasha Tatashin wrote: > > > > > HugeTLB pages have a struct page optimizations where struct pages for= tail > > > pages are freed. However, when HugeTLB pages are destroyed, the memor= y for > > > struct pages (vmemmap) need to be allocated again. > > > > > > Currently, __GFP_NORETRY flag is used to allocate the memory for vmem= map, > > > 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 retri= es, > > > and will fail only when there is genuinely little amount of unused me= mory > > > in the system. > > > > > > > Thanks Pasha, this definitely makes sense. We want to free the hugetlb > > page back to the system so it would be a shame to have to strand it in = the > > hugetlb pool because we can't allocate the tail pages (we want to free > > more memory than we're allocating). > > Agree. > > The hugetlb vmemmmap freeing series went through more than 20 revisions > before being merged. One issue with much discussion was the need to > allocate vmemmap pages when hugetlb pages were returned to buddy. > > It looks like the current set of GFP flags was suggested here: > https://lore.kernel.org/linux-mm/YC4ji+pMhtOs+KVM@dhcp22.suse.cz/ > > Although, it was also mentioned that __GFP_RETRY_MAYFAIL could be used > instead of __GFP_NORETRY here: > https://lore.kernel.org/linux-mm/YCafit5ruRJ+SL8I@dhcp22.suse.cz/ > > Adding Michal on Cc: since these were his suggestions. Thank you for the background Mike. I have sent the 2nd version, and added Michal into that patch. Pasha