From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADEDC4398FA for ; Thu, 30 Jul 2026 14:13:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785420814; cv=none; b=bek6lZxOgqqfj19gCYBraJIW6AYDSaKBkoBY9xVKSfYLRxRSFy+FyZU7mY8aBjyqPB31xPyH0UXlbAPWq1g7LpOO1vP5uc/O+nvuSVkPwwRti3ZqrGrx/Vi2Bt/cOVCXFiNajEg5F+tHRXBGUaxJwAuZMtGChlI0/VsXuB5tuNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785420814; c=relaxed/simple; bh=Hav448WQglAeJfIVDkQG66BKGv/w2yMHVGM9cIcSMEY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=f4TgLqnfcaq23fk9FurEChJRXw0i3I4+r6PzS1kt6Bts8sXNGg35Wb8FnvfFmxH5DmaHnDRHRiaJ60Hcxu33XmMcsA1n2Pw19fGMR5GuH1b1xd2eauJiHMaW+15sr85T16zqNgYtw6t3cSvMIorPNfmr6+gLHHXps5MoeIHMcHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=I11whn3X; arc=none smtp.client-ip=209.85.219.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="I11whn3X" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-8f186025973so21019606d6.0 for ; Thu, 30 Jul 2026 07:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1785420810; x=1786025610; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=QLkNt2H80eZrmEFB7rGaX5sD5ucgaW5cZGvSCwvv5/E=; b=I11whn3Xj9L/O2JllZcs7W/FHE32wX5Vf1zE6rMOVZzBbyajXJnEkAjIWnaemIUUlU fQgTZtx6m9iTQZp4r9byYd/HuI5bWhZLC8wfJ5ODPg1yhQ2l9x1DmXDUVo6a89sm2Ak9 cG5t11qgOd2rT9S7/gQaqq9IuXL8cHWZn5joW+uqxa6acrvJp+1hoxhgtiNnqRgy3y41 C70mQ3lb6YhJbg+TBVZlRramwTcPf8zT8vDAmNkGNuCSbzV7ZDCy8xJ1+G65zjmGPh7g ZXC8pumqDdMkzyugP86hBoNF6VaNPBsXOtNkhUDK1NeaRa2z/0oygXEsstQoaVgJSVas LeVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785420810; x=1786025610; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QLkNt2H80eZrmEFB7rGaX5sD5ucgaW5cZGvSCwvv5/E=; b=TLHzii1NiKwHVOpfwozr9YETSrGAUwOBa4/J78aqEQ7IJRWqRpIYdI3qsTFMJdmKbV gm/yAZrkI9AjzDe0/n8pFV0cxcLlnlfjx4u50ceaUKy5UMuET8IRVscH2sdtv3ny50iS bqw3Le91uA+15ymuju6yaT1T3uAfb61NGBIh+gEVCYlBofkI2E3p7T3D6hsmExPdHDAn YE0p8igWgCqYoOtFpLG2yyAgIZHb5iht20C4KkfRPCXiViXVyFY1MY3hx2HPv1masoxD y+qJKPQ7mKnApxuyHBgRZefkR6DNQpeZ+k+S/LInHFn5iNJVMekEU/xwPs1UQPyTvNsz rD3g== X-Forwarded-Encrypted: i=1; AHgh+Rq0fAWZ3G3DWmETPShoB/+GgB5udmLF/DfQMOAjatP8yYof0wzLtWXd9iccOA+3S5KYzGwHKSOVSTDahzU=@vger.kernel.org X-Gm-Message-State: AOJu0YxcIRt7/ODSc6CFSRrK4X/y4M5mZs5TY4TLCvYYysPoS3kJcoZ+ 8YI5SKkGJJ3fvEYejw7eM1rXp9U0WfKdC5NCd1oCMBSDEVHnqXa6yl44uGfG1xBPufeRO8a2uKf Cz/m3 X-Gm-Gg: AR+sD12EnMFFoqR5vdFLJqBYUa3D76N0rSB5koWz6tWjaWlnbePaX4f1xVupmc/3ILv lRIo0dTgOY0YUao4m4TK6Rwv4wrSPpVewG7qtOCAl6OS0A711DQldkuu/Qk14Z+6txM0Avt4cQ0 fdRd+J92xCX/MdQbpfxt6VrMcydDihLuabVuXerDzuh3WXgxd5JtuAh9qhDEy5cxPlChi76TH4R NrJAGCubG4YQEa6RdPgArBqwBm8b+klPdmpzQqn76JhgldY7l0IXfgeg0aDiLRJf1RloY4aN2cy kDhDDJ4VCrfnTI4RufFFdIIou90WMKtir2t9COnSasvCi3WQA6e2l/+5U2MKdDFZ9YYiAjHEV1O hXyzF+hJIjwk6fcgl98wodTh5Ff7KcBj1ZTuoo6o+163dFQ9n0aj/e4Cfyu2h04j9cOl/S/Wkxw dhDExvbcJ0G/w2wv+iPR981mpVNUJ1SfHRTGF23JSyOYX1T+i6ujTAgKIWF/8= X-Received: by 2002:a05:6214:5a0c:b0:8ee:39bc:8fb4 with SMTP id 6a1803df08f44-908347a8e44mr25915246d6.33.1785420810359; Thu, 30 Jul 2026 07:13:30 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-908323eb758sm18842216d6.28.2026.07.30.07.13.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 07:13:29 -0700 (PDT) Date: Thu, 30 Jul 2026 10:13:25 -0400 From: Johannes Weiner To: Zi Yan Cc: Andrew Morton , Matthew Wilcox , William Kucharski , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC] xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc() Message-ID: References: <20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260727-add-gfp_account-to-xas_split_alloc-v1-1-9fae6bf64838@nvidia.com> Hello Zi, On Mon, Jul 27, 2026 at 09:51:40PM -0400, Zi Yan wrote: > XArray operations that allocate xa_nodes, such as xas_nomem() and > xas_alloc(), add __GFP_ACCOUNT when the array has XA_FLAGS_ACCOUNT set. > This charges the allocated memory and avoids the workingset convergence > issue described by commit 7b785645e8f13 ("mm: fix page cache convergence > regression"). > > xas_split_alloc() does not have that flag. Add it when necessary. > > Fixes: 6b24ca4a1a8d4 ("mm: Use multi-index entries in the page cache") > Signed-off-by: Zi Yan > --- > Hi Johannes, > > IIUC, __GFP_ACCOUNT is needed for xarray node allocation accounting when > XA_FLAGS_ACCOUNT is set. Commit 7b785645e8f13 ("mm: fix page cache > convergence regression") fixed a workingset regression with it. > xas_split_alloc() does not have it, so I imagine xa_node allocated during > folio split would cause a similar issue. I would like to get your > opinion on this. Yes, you're right! As we had discussed on the THP cabal call, we should use the memcg context of the folio, as that could be different from the callers' depending on who's doing the splitting. I.e. memcg = get_mem_cgroup_from_folio(x); old_memcg = set_active_memcg(memcg); xas_split_alloc() / xas_try_split() set_active_memcg(old_memcg); mem_cgroup_put(memcg); There is __folio_split() -> xas_split_alloc(). But there is also __folio_split() -> __folio_freeze_and_split_unmapped() -> __split_unmapped_folio() -> xas_try_split() -> XA_FLAGS_ACCOUNT -> __GFP_ACCOUNT. So it would make sense to me to set up the memcg context in __folio_split() already.