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 B8D61C6FA8E for ; Thu, 2 Mar 2023 23:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25F6F6B0073; Thu, 2 Mar 2023 18:21:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 211AA6B0074; Thu, 2 Mar 2023 18:21:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D84F6B0075; Thu, 2 Mar 2023 18:21:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 002386B0073 for ; Thu, 2 Mar 2023 18:21:58 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9E6AD1C5CA5 for ; Thu, 2 Mar 2023 23:21:58 +0000 (UTC) X-FDA: 80525533116.23.861AD8B Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf21.hostedemail.com (Postfix) with ESMTP id A36681C0014 for ; Thu, 2 Mar 2023 23:21:56 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bjVMOdcr; spf=pass (imf21.hostedemail.com: domain of zokeefe@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677799316; 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=Umr5zRx7LZxoXNofPxvfrNl/FxEmafsnTcc+zwDql1Y=; b=6CztRVD465nq6gjhrzQZ0Cs5InCRTu2GxBj6xA8qPuN2ItkcIkmz7bANncm63kL9GCZQAg GsCsbuT/iySH7M6lBauea/DkS6utXtobi5gZB3grPSI1EVYbQjOh9oqCUHlxZgf2wMJm1h q/7wzBjd0rl8b6BiFYv7f9smK8i1YY0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bjVMOdcr; spf=pass (imf21.hostedemail.com: domain of zokeefe@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=zokeefe@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677799316; a=rsa-sha256; cv=none; b=lGGItFXnz6Fox1H3J8FVppm6KMYv6D/WkwNeTsbF/UXSF4aBeSQsHnS/uU4hMFpUCOYmgo IVpFkdewi8TD1nn+GrySOuXgwMSCBMIKOrJuHxmCE85Bd/QfZNgtvbIww/Qg1Y+u4FsnJ2 e9ZjrsyqSdNqW8PmYLzmu5OmiB1Qpe8= Received: by mail-pl1-f174.google.com with SMTP id i10so906269plr.9 for ; Thu, 02 Mar 2023 15:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677799315; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Umr5zRx7LZxoXNofPxvfrNl/FxEmafsnTcc+zwDql1Y=; b=bjVMOdcrNxLuBiLEEFaIZR1mK9cdnzdjwLURuJelQ3ERIrmgP2fukYOz8nwdnGsAnF JUJX3ta1SokzeqQUrlPbjL4RO1qRlfv5gOEekLKDIujED2QJcHbPHImJUY2FsIC03ObR j0tDp7MzEy8YA4v7eGx9k9nHT93n3YTsuxUwn4efxhFG3dPiVi2sAFevjDoCgMk0Xiaf pWuoVGDECCNV8IIwBNH5YQURCdONqPcr6f1V7aCxPzRqmEWGspwrwtUHKWH1qFXyPPlZ SUK4aPrIJebGQtlpWbUJ2+XH8tpCSom5TeJG6+FVwWXjJ2Q+boERTBI4Tz9yIaN3PXr2 MdFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677799315; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Umr5zRx7LZxoXNofPxvfrNl/FxEmafsnTcc+zwDql1Y=; b=UBSbSachIktbhT4lrDbmHSN8Ge8xT3QDgR44phifhlL59lNWDYxOggnGFv7ULpGUNb 3dz3OHAwtQVsFBhilK6mUHSRZbDrThpvoBA2TvSu8B+IhJK9NLtRn46xUDtyZ7DF5TK5 Wt964XRkVHsdkOWkTuH7Ee2Tiv+YFyfXuxck9+UX1EkE5wKZeWCNy2M+rQVJBM0ULuHj vr1WG4T683DjjYaVwGoFXiWwJEFpWjQjOGbGXTep2B/3Tvxh73JgW7a1+J8lhodxlGsd 92ccCTlbnZj1dKJmkK+DtnkrUT8nwYCz7IbLQ62MbYFF7p+qFm8Q7+Uskv5+00DEAJCu UOyQ== X-Gm-Message-State: AO0yUKVQRyTCqtefXO6Mo+mPEdyKKJPKRjQ4a4dvRbMU1zINZYPGCMn3 jSGgVt4+++TDZ9HCULXdREw3DQ== X-Google-Smtp-Source: AK7set+hdJvu6FUSLpeOiGsfK3pztUXRbikU8bYd/VGaiU29pfxrCV9E0XIcb953CRcsnF/fFIqCBQ== X-Received: by 2002:a17:903:6cb:b0:198:af50:e4e6 with SMTP id kj11-20020a17090306cb00b00198af50e4e6mr81056plb.12.1677799315123; Thu, 02 Mar 2023 15:21:55 -0800 (PST) Received: from google.com (33.5.83.34.bc.googleusercontent.com. [34.83.5.33]) by smtp.gmail.com with ESMTPSA id b9-20020a63d809000000b0050300a7c8c2sm183711pgh.89.2023.03.02.15.21.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 15:21:54 -0800 (PST) Date: Thu, 2 Mar 2023 15:21:50 -0800 From: Zach O'Keefe To: Yang Shi Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , David Stevens , Johannes Weiner Subject: Re: [PATCH v2] mm/khugepaged: alloc_charge_hpage() take care of mem charge errors Message-ID: <20230302232150.vvmszlrdzqm5ndjq@google.com> References: <20230222195247.791227-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A36681C0014 X-Stat-Signature: ggaze5ica18e7yiism3nztsujspjgp6u X-HE-Tag: 1677799316-172819 X-HE-Meta: U2FsdGVkX1/lq6UcxqbEecwwxOiSeByCQahFvy7DZ/2kX08Jb+8/uBptTxUiVu8rM3Yg77LaRXdPygdeMFRpfVHSftno+M0eWImgRv0lOMKQEOGF7p3F3l+0PFwPp459RZ3piy9SGfsIK+BVPoPTvnoNu19XCQJGGNVqH872vL2m6ng73s591atSJhs8nPsyT0h+BylItSTH+OIDpLyep+cZTOjhcvW3A01xIb5YUhDiyxuHHKoxD4G5SScigawIVKhgiJh9W5t7I8eKqx4n8nwUZ6iEwWYx47blb6AzdXfFpo0CFZ/FIFczjZzkWYEu5udEKgS8QwGZGQ1UhFnhGPRq9lmf+c9q012rdAPWs54frfIO51wlvA4DCqs/Q6njpPdwXkVp59779mg1kt+WeK7eR9eUr5P606srAWVpNTvbA/eBUP5AG+luNM6Wib9leLcBY11TYwP0JRFpGsNB40/gwkrMw+frdwaHX65RDRM5P9hg5R329a33315DIYr71hc19szl+1H+eoav739DgXfXfKOE0B3olvvDkvzDjhOipyKV6qYNBbMWBf7wVKDT1E6LCUSyB7IJ6Kujhv+q3EjdKRQg6eBipSx7dxGNOPnc1tVv1EEhm6Ex04txCT7LxZzGLByGBsb9muaJlDyXkPlQO0czpAwjYF+8ek7RkNfT3KrKVm/6HxZT4dmLyUxp8bTHQIl7lksVt2+er1dWRsP/TLmnsrzLY8wpONPyN2Q+cqhB0IuRMY0krLFHp9bOf6xkRJAsplR7Mg3B4yXqbiIX1iRdrp1/eUFX3uLsumvysqfX4oK2EISC8WLo5lUCNEbXu0tHymDsN6G0B1A+gOAFQkw3N6AudsxGBywt4Ac/c/AG1oriu50nrrwgfL9/CwIxXe5PnVf7951cGQqHuN1n1bHf4b+/Vhk/mpPJiFkco1gygY2S8/F6qX3YfhEDaiDq2igBrJewg7O7LRW dBf8cdYf aEjya6qVFcPdhJc3jRo+yVPBD+ZDi2ja1WiZC5yz4IV0zZtYoBPSk3f+9PQ3b1CWGPw5bYeAqDsxjvbnH2zKhpXmcCs5Uj5oj7tYIPyPEMVFs60qtZkG/j/NLfZiL4g4XeRPVkqK4ZUc3eFkIBwPSnTFZjw1ZVBzkGSoy0M3SysCi++YyLB+qGYsgmd6MuuL8YfT2k+Mp9s+ZAIlQBniFHo3epsueAHPlWrp6Xu54ZIiZTf16Qp7+BsTjHkbA5JgGS5pDh/t546iuZTH54JEsT8lHGuIBMkps68bKUlMMDuswlpcJH+Zyfttp8XrcUeiEveEwobnH1XHoIiuDnfP+ty8A2c9d63rjsVbvd7EyYbc3dJPFLdqyEDma2FVau44V7o+VHJr5acquiW1BtUuuSfAvELPqrzKLDzsXBZv5vaqb+CwxfLLrUwAfsutipXR1NNN4jkZw06yl5jGQUOZXALdtoHbygLOp97fONW1Jooaj1/1mSE7VyXpWyrqqoq3OaTSGY5G2bjMkVo69ztx6Qwgr91vu+Njx+074MSWyiCMerQMxmE+oR+1FMcm5Jamg0+lFynSqp+FVJFYhXZnNE5qv6o7bHxveVdk/+4vGdyrsoFU= 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 Feb 22 14:53, Yang Shi wrote: > On Wed, Feb 22, 2023 at 11:52 AM Peter Xu wrote: > > > > If memory charge failed, instead of returning the hpage but with an error, > > allow the function to cleanup the folio properly, which is normally what a > > function should do in this case - either return successfully, or return > > with no side effect of partial runs with an indicated error. > > > > This will also avoid the caller calling mem_cgroup_uncharge() unnecessarily > > with either anon or shmem path (even if it's safe to do so). > > Thanks for the cleanup. Reviewed-by: Yang Shi > > > > > Cc: Yang Shi > > Reviewed-by: David Stevens > > Acked-by: Johannes Weiner > > Signed-off-by: Peter Xu > > --- > > v1->v2: > > - Enhance commit message, drop "Fixes:" and "Cc: stable" tag, add R-bs. > > --- > > mm/khugepaged.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index 8dbc39896811..941d1c7ea910 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -1063,12 +1063,19 @@ static int alloc_charge_hpage(struct page **hpage, struct mm_struct *mm, > > gfp_t gfp = (cc->is_khugepaged ? alloc_hugepage_khugepaged_gfpmask() : > > GFP_TRANSHUGE); > > int node = hpage_collapse_find_target_node(cc); > > + struct folio *folio; > > > > if (!hpage_collapse_alloc_page(hpage, gfp, node, &cc->alloc_nmask)) > > return SCAN_ALLOC_HUGE_PAGE_FAIL; > > - if (unlikely(mem_cgroup_charge(page_folio(*hpage), mm, gfp))) > > + > > + folio = page_folio(*hpage); > > + if (unlikely(mem_cgroup_charge(folio, mm, gfp))) { > > + folio_put(folio); > > + *hpage = NULL; > > return SCAN_CGROUP_CHARGE_FAIL; > > + } > > count_memcg_page_event(*hpage, THP_COLLAPSE_ALLOC); > > + > > return SCAN_SUCCEED; > > } > > > > -- > > 2.39.1 > > > Thanks, Peter. Can we also get rid of the unnecessary mem_cgroup_uncharge() calls while we're at it? Maybe this deserves a separate patch, but after Yang's cleanup of the !NUMA case (where we would preallocate a hugepage) we can depend on put_page() do take care of that for us. Regardless, can have my Reviewed-by: Zach O'Keefe