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 77B55C48295 for ; Mon, 5 Feb 2024 14:47:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF9A56B0082; Mon, 5 Feb 2024 09:47:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8C966B0083; Mon, 5 Feb 2024 09:47:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A23666B0085; Mon, 5 Feb 2024 09:47:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8FB0F6B0082 for ; Mon, 5 Feb 2024 09:47:36 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 486B1120A90 for ; Mon, 5 Feb 2024 14:47:36 +0000 (UTC) X-FDA: 81758028912.24.8A13686 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf05.hostedemail.com (Postfix) with ESMTP id 0D320100021 for ; Mon, 5 Feb 2024 14:47:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oFciRSqf; dkim=pass header.d=suse.com header.s=susede1 header.b=oFciRSqf; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707144454; a=rsa-sha256; cv=none; b=BPfzFYRfVtPzWnAoWE+fNDBl2Y1GUlxsSE80nKI7sT3kSj5BMyBuoIzWRfggERl/qVF5FM ndSjTy0qduwbCgboSw4ywgeAVigjt+P+CLmcSd8gHQpOxqp/GQ/nL6SBLE3JJRMRDPaSZ+ wry//EpnvftJ34oEmsoTnR75dNU13KE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oFciRSqf; dkim=pass header.d=suse.com header.s=susede1 header.b=oFciRSqf; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707144454; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yYUoybHLUqZci7jTkA5AStGSRfMnYOuNTneWtGHo/yU=; b=Rg9HIiOSgozXli4qaIAZZtWHzpTy7EnYAKGoWtUxyaDw726gZB17ayOI53nXRxnauV2zcR HHPmumKxATyQb8YwKvMevfHg3qaW3qPX+KiM3HwVcHtpXe7005JaylfXxdCse31MCWJYln g6AnwZAKcYM9DSpcCPS+K67IjwOKAws= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 4DBC2222BC; Mon, 5 Feb 2024 14:47:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707144452; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yYUoybHLUqZci7jTkA5AStGSRfMnYOuNTneWtGHo/yU=; b=oFciRSqfH+243AnA0GHa7gBzsKGpQHVouFXoNeyaCJrdf++ciV2GKWVGuP+H4BT9Ykk+qT UXza7O3LHjkQi9Mwy1a7/ZFGSuhuSsXQhHOCM6PyEhSYWGKqHvlgSu33PKxorW3Y+mgRcv 4lUcVxv/f6jeVtdgvrYTToHK1MesMCo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707144452; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yYUoybHLUqZci7jTkA5AStGSRfMnYOuNTneWtGHo/yU=; b=oFciRSqfH+243AnA0GHa7gBzsKGpQHVouFXoNeyaCJrdf++ciV2GKWVGuP+H4BT9Ykk+qT UXza7O3LHjkQi9Mwy1a7/ZFGSuhuSsXQhHOCM6PyEhSYWGKqHvlgSu33PKxorW3Y+mgRcv 4lUcVxv/f6jeVtdgvrYTToHK1MesMCo= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1E11313A2E; Mon, 5 Feb 2024 14:47:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id LEY9BQT1wGUQdAAAD6G6ig (envelope-from ); Mon, 05 Feb 2024 14:47:32 +0000 Date: Mon, 5 Feb 2024 15:47:31 +0100 From: Michal Hocko To: Baolin Wang Cc: akpm@linux-foundation.org, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: hugetlb: improve the handling of hugetlb allocation failure for freed or in-use hugetlb Message-ID: References: <23814ccce5dd3cd30fd67aa692fd0bf3514b0166.1707137359.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23814ccce5dd3cd30fd67aa692fd0bf3514b0166.1707137359.git.baolin.wang@linux.alibaba.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0D320100021 X-Stat-Signature: mhkfgg574c4zycuu58hkqz64h65a6mdt X-HE-Tag: 1707144453-322288 X-HE-Meta: U2FsdGVkX1/eP2JgsYl3YdsROWLKcAL1/66vJMkV8vWbsfjCe8mVckHbC45XCuNCmAeD1PmQ9Mb8RrRLjFpSV53IiqMCcP15aRMbl5wXiOrkTe214S08XYmNG64KcTHNOru3f2qsJPoEG2wv2JgYQp1qZtX9ryj7412qJdwa3VQmYkBCiLIyqZlD0+Jy8WcnPiKU7XOW9HZOXuw8bBpXzG+007uc3mQ+Qsv/KxvEoEHcAZcYYzQEYqu0i18Max2wEubZq1skTIyXyC3wPlD0afULj4Kee7Gn6o8fEELqLE/AmGY0nroBEPbgrtmK8JB2MdSVUbDd3eMRVvh0GD9kr4eRJcGQbqON5Oq2XJtc25rFzp4nZAUh53Hkb8PMwNOYJesX9KQ2OWd7+QrAiaeGBmNQprstU0VJgGj6VLHqQllUZR8E6TD40gX6Hdzur0ZagFcRk9qipoHUI95CjEaEkSgUITDSP+u/jb1HxdItQym3+CIzhdJjcgNkXYpUQTkPj74jJNzXFqecsEmO46ny0lgpbDkubzgmMvSR85lfkF76rRcUWzuVpOtjsw7/FKqMH78DFZv/e//xI+DlBEBtZEQQw22JbWZKUM6ROuwWb512T0Fne3TiS8aLpPi1BcEJ5zW+il9z0sUHmsiidxfNP4MdEO8Z5jqNNdwr1gW1X0lNGiVD5bAJHS2cn5/4HUeZaryv7HPyCo1OdlW9HFVtDWGTO6Wh2FXvWOlEu1KF3s3C2lwQ3/hT1zB6UoLT2H+oa0wRwP/EZ/qTzZR+JYzkua4XwGeCqHvzxYJGulwSe5l6dc3u64qtHahTIMZ7s8sBw+HPu5YFqS76YQ/zwRo8aiS9fEhyd6nDEBtDtoxmN86EBI6Zlyi4Zqsw3NQ9KiVIRd/cGYNGVes+B82BtH45t4zaeU8knha6Mv9+OcEXz/7aWHOfNl330xGV7O8RwvrF9d/AeWKUl3jrTel05QZ KllmnJyY 6sv1yO3UmOV6dHF39R4wGMRmoCMdAslPwakJSHMUb4coYzpsQsFTR2kwAOGZErHFY4XWHji0pXwwkVydMqPNczxNpDjl7+PHunNThhWwm30r7PZ7OocJzYUF4AXzfRDzZMFfsngCAQNdZC22jIJwIH2Ue0HZOHLKSAeA2iOxkWOJzWvOgb3QV2nrLFgSZI+g4fHuVy1Et0/H71kMV8ZTwH3tkWg== 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: List-Subscribe: List-Unsubscribe: On Mon 05-02-24 20:50:51, Baolin Wang wrote: > When handling the freed hugetlb or in-use hugetlb, we should ignore the > failure of alloc_buddy_hugetlb_folio() to dissolve the old hugetlb successfully, > since we did not use the new allocated hugetlb in this 2 cases. Moreover, > moving the allocation into the free hugetlb handling branch. The changelog is a bit hard for me to understand. What about the following instead? alloc_and_dissolve_hugetlb_folio preallocates a new huge page before it takes hugetlb_lock. In 3 out of 4 cases the page is not really used and therefore the newly allocated page is just freed right away. This is wasteful and it might cause pre-mature failures in those cases. Address that by moving the allocation down to the only case (hugetlb page is really in the free pages pool). We need to drop hugetlb_lock to do so and therefore need to recheck the page state after regaining it. The patch is more of a cleanup than an actual fix to an existing problem. There are no known reports about pre-mature failures. [...] > @@ -3075,6 +3063,24 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, > cond_resched(); > goto retry; > } else { > + if (!new_folio) { > + spin_unlock_irq(&hugetlb_lock); > + /* > + * Before dissolving the free hugetlb, we need to allocate > + * a new one for the pool to remain stable. Here, we > + * allocate the folio and 'prep' it by doing everything > + * but actually updating counters and adding to the pool. > + * This simplifies and let us do most of the processing > + * under the lock. > + */ This comment is not really needed anymore IMHO. > + new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid, > + NULL, NULL); > + if (!new_folio) > + return -ENOMEM; > + __prep_new_hugetlb_folio(h, new_folio); > + goto retry; > + } > + > /* > * Ok, old_folio is still a genuine free hugepage. Remove it from > * the freelist and decrease the counters. These will be -- Michal Hocko SUSE Labs