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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 21452C433DF for ; Fri, 16 Oct 2020 14:54:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 551F420874 for ; Fri, 16 Oct 2020 14:54:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="LfWcB5jJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 551F420874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4ED216B005C; Fri, 16 Oct 2020 10:54:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49B386B0062; Fri, 16 Oct 2020 10:54:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38AFE6B0068; Fri, 16 Oct 2020 10:54:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 8C7C36B005C for ; Fri, 16 Oct 2020 10:54:47 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 365A0181AEF1E for ; Fri, 16 Oct 2020 14:54:46 +0000 (UTC) X-FDA: 77378085372.27.mouth75_040cbd72721e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 173543D669 for ; Fri, 16 Oct 2020 14:54:46 +0000 (UTC) X-HE-Tag: mouth75_040cbd72721e X-Filterd-Recvd-Size: 5065 Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 16 Oct 2020 14:54:45 +0000 (UTC) Received: by mail-io1-f65.google.com with SMTP id n6so4074750ioc.12 for ; Fri, 16 Oct 2020 07:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=P+wWygljj49b/Jwoyua6AHD+Ku/LFmb5gdhqTAfvLEg=; b=LfWcB5jJyrh0MulkzzuGDm88OUPUpKQE8o53FteBypfuv4DTJIqcilO5fbMfXFgYXI lNzpYppun7sYKDcWP9drg2dRRpqy3ivRLLdyLTh5O5yrcim1D+Rl1p43Fc8Ww1Dlnq75 UduIWxVs7cKdmtuQ99t4hyO12AovSFAZgo1uUGJ5obm0Il7FaQHkzj9QMdXK9zopXcSF PLwlynbaqdXAtnJzQ89MJ+Lzr1Vb/40fbGXEsslJk7dWbQwUd777LR4USiIBmWG9Zm6f 7A4U32UBKsGWK71FaDROAEtzkzsNLPZWM6FOj2Bt9j8CrzMDRFddJUzI7S5C99xjuZd5 KqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=P+wWygljj49b/Jwoyua6AHD+Ku/LFmb5gdhqTAfvLEg=; b=KDJ3jc3uV1nwqYK2b7qcHiuk7TCEHq4yBzZeIoYib/DC1SZlETwdyUKSCNE7xCo231 6ZbK9tP7a1RWItyCCktC4S46aFaitTX5IcIhvxReRM7vt3YhOdngyQ22CPEfI8SZwdFV aeSUUKdJBxGchaRL/aTz50Yz7K2KVCscUKbb+F6/JtrvCshTNG7BjnnwaRxMCrBRnjSp rUPmpC5+YbxKsCi5wR8jMwAgc8A9zWMZpmqqvHGRMJCNcHBLCHnNnhMoNbdUQahjZfrH rXpMS6e+1YcOOiKTu4r1tpSnlhal+lfO2m2tyiHXbsmX93MQKXlS5vgLof42yT7FC3KV Om1Q== X-Gm-Message-State: AOAM531tc4Lz+HyPgzFmlgKa/F8iPWzJKrG7YIpFrcUVLn9QTA+vUjSX lVuftW23EfKXjRAfDH1cT5rgeg== X-Google-Smtp-Source: ABdhPJzFogEG6IQkoTlKAgWk1KT+gJK3ZP6L/JPWVdkauPYFnSZXzWhrRw9D+btj4vw97vn8oJI+tQ== X-Received: by 2002:a02:9441:: with SMTP id a59mr2934832jai.122.1602860084430; Fri, 16 Oct 2020 07:54:44 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:b51d]) by smtp.gmail.com with ESMTPSA id b14sm2815853ilg.63.2020.10.16.07.54.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Oct 2020 07:54:43 -0700 (PDT) Date: Fri, 16 Oct 2020 10:53:08 -0400 From: Johannes Weiner To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: Richard Palethorpe , 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 Message-ID: <20201016145308.GA312010@cmpxchg.org> References: <20201014190749.24607-1-rpalethorpe@suse.com> <20201016094702.GA95052@blackbook> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20201016094702.GA95052@blackbook> 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: On Fri, Oct 16, 2020 at 11:47:02AM +0200, Michal Koutn=FD wrote: > Hello. >=20 > On Wed, Oct 14, 2020 at 08:07:49PM +0100, Richard Palethorpe wrote: > > SLAB objects which outlive their memcg are moved to their parent > > memcg where they may be uncharged. However if they are moved to the > > root memcg, uncharging will result in negative page counter values as > > root has no page counters. > Why do you think those are reparented objects? If those are originally > charged in a non-root cgroup, then the charge value should be propagate= d up the > hierarchy, including root memcg, so if they're later uncharged in root > after reparenting, it should still break even. (Or did I miss some stoc= k > imbalance?) Looking a bit closer at this code, it's kind of a mess right now. The central try_charge() function charges recursively all the way up to and including the root. But not if it's called directly on the root, in which case it bails and does nothing. kmem and objcg use try_charge(), so they have the same behavior. get_obj_cgroup_from_current() does it's own redundant filtering for root_mem_cgroup, whereas get_mem_cgroup_from_current() does not, but its callsite __memcg_kmem_charge_page() does. We should clean this up one way or another: either charge the root or don't, but do it consistently. Since we export memory.stat at the root now, we should probably just always charge the root instead of special-casing it all over the place and risking bugs. Indeed, it looks like there is at least one bug where the root-level memory.stat shows non-root slab objects, but not root ones, whereas it shows all anon and cache pages, root or no root.