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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8675FC433DF for ; Mon, 19 Oct 2020 08:45:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C18562225F for ; Mon, 19 Oct 2020 08:45:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C18562225F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C53DB6B005D; Mon, 19 Oct 2020 04:45:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C051F6B0062; Mon, 19 Oct 2020 04:45:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B427C6B0068; Mon, 19 Oct 2020 04:45:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 870C46B005D for ; Mon, 19 Oct 2020 04:45:36 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 17605180AD815 for ; Mon, 19 Oct 2020 08:45:36 +0000 (UTC) X-FDA: 77388041472.15.brake20_530111f27235 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id E92E81814B0C1 for ; Mon, 19 Oct 2020 08:45:35 +0000 (UTC) X-HE-Tag: brake20_530111f27235 X-Filterd-Recvd-Size: 2641 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 19 Oct 2020 08:45:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 111FFAC8C; Mon, 19 Oct 2020 08:45:34 +0000 (UTC) References: <20201014190749.24607-1-rpalethorpe@suse.com> <20201016094702.GA95052@blackbook> <20201016145308.GA312010@cmpxchg.org> <20201016171502.GA102311@blackbook> User-agent: mu4e 1.4.13; emacs 27.1 From: Richard Palethorpe To: Michal =?utf-8?Q?Koutn=C3=BD?= Cc: Johannes Weiner , Roman Gushchin , ltp@lists.linux.it, Andrew Morton , Shakeel Butt , Christoph Lameter , Michal Hocko , Tejun Heo , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm: memcg/slab: Stop reparented obj_cgroups from charging root Reply-To: rpalethorpe@suse.de In-reply-to: <20201016171502.GA102311@blackbook> Date: Mon, 19 Oct 2020 09:45:32 +0100 Message-ID: <87lfg2ob83.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Hello, Michal Koutn=C3=BD writes: > On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner wrote: >> The central try_charge() function charges recursively all the way up >> to and including the root. > Except for use_hiearchy=3D0 (which is the case here as Richard > wrote). The reparenting is hence somewhat incompatible with > new_parent.use_hiearchy=3D0 :-/ > Yes and it also seems new_parent.use_hierarch=3D0 -> new_child.use_hierarchy=3D0 and new_parent.use_hierarch=3D0 -> new_child.use_hierarchy=3D1 are considered valid on cgroupsV1. The kernel will also allow more descendants on new_child.use_hierarchy=3D0, but sets broken_hierarchy=3D1. However this will not stop the stack trace occuring (AFAICT) when the reparenting happens between two descendants. >> We should clean this up one way or another: either charge the root or >> don't, but do it consistently. > I agree this'd be good to unify. One upside of excluding root memcg from > charging is that users are spared from the charging overhead when memcg > tree is not created. (Actually, I thought that was the reason for this > exception.) > > Michal --=20 Thank you, Richard.