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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17F2BC433F5 for ; Fri, 27 May 2022 17:48:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353327AbiE0RsB (ORCPT ); Fri, 27 May 2022 13:48:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231767AbiE0Rr6 (ORCPT ); Fri, 27 May 2022 13:47:58 -0400 Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E21717A88; Fri, 27 May 2022 10:47:56 -0700 (PDT) Date: Fri, 27 May 2022 10:47:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1653673673; h=from:from: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; bh=GyZxhrFIbciyaIa9/uGSSo/bdh7XAme4AdSjV5SMRRg=; b=ZqRzG1adM/lY8etIuMIydjIQZ2VDwDQ5EbKSiqF0cCHyjgI7PSsx0GyLAGXqymvqrQRzFy m6d0oBpA7fhs0ygGeSr6RnfWTd1tWH9vTAM0+lt4j3iZs9fDLjDmE6+9DdMx46FFB12loF fpzD0JKuyQ8nOhyDo8hiz7eW4QtIg5s= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Vasily Averin Cc: Shakeel Butt , Johannes Weiner , kernel@openvz.org, LKML , Matthew Wilcox , Cgroups Subject: Re: [PATCH] XArray: handle XA_FLAGS_ACCOUNT in xas_split_alloc Message-ID: References: <348dc099-737d-94ba-55ad-2db285084c73@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 27, 2022 at 02:22:19PM +0300, Vasily Averin wrote: > On 5/27/22 04:40, Shakeel Butt wrote: > > On Thu, May 26, 2022 at 6:21 PM Matthew Wilcox wrote: > >> > >> On Wed, May 25, 2022 at 11:26:37AM +0300, Vasily Averin wrote: > >>> Commit 7b785645e8f1 ("mm: fix page cache convergence regression") > >>> added support of new XA_FLAGS_ACCOUNT flag into all Xarray allocation > >>> functions. Later commit 8fc75643c5e1 ("XArray: add xas_split") > >>> introduced xas_split_alloc() but missed about XA_FLAGS_ACCOUNT > >>> processing. > >> > >> Thanks, Vasily. > >> > >> Johannes, Shakeel, is this right? I don't fully understand the accounting > >> stuff. > >> > > > > If called from __filemap_add_folio() then this is correct. > > > > However from split_huge_page_to_list(), we can not use the memcg from > > current as that codepath is called from reclaim which can be triggered > > by processes of other memcgs. > Btw, Shakeel, Johannes, > I would like to understand, when Xarray should use XA_FLAGS_ACCOUNT ? > > From my point of view, this should be useless: > a) if Xarray stores some index (idr?) - his memory is quite small, > and his accounting can be ignored. > b) if Xarray stores some accounted - the size of the corresponding Xarray > infrastructure is usually significantly smaller than the size of the stored object, > sо his accounting can be skipped too. > c) if Xarray stores some non-accounted objects - it makes no sense to account > corresponding Xarray infrastructure. In case of necessary it makes much more sense > to enable accounting for stored objects (and return to case b). > > Am I missed something important perhaps? > > I looked for the description of 7b785645e8f1, but o be honest I'm still not sure > that I understand correctly why XA_FLAGS_ACCOUNT flag solved the described problem. > > Could you please explain this in more details? > > Was it because the non-accounted Xarray kept a reference to the stored object > and thus prevents it from being reclaimed? > > If so, was it some special case, or should it affect all such cases, > and my b) statement above is not correct? It's all about shadow entries, which are small, so b) is not true for them. There is a good description on how it works on top of mm/workingset.c