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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=ham 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 62BE7C433C1 for ; Fri, 19 Mar 2021 18:28:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E1F5461981 for ; Fri, 19 Mar 2021 18:28:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1F5461981 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7FE2F6B0078; Fri, 19 Mar 2021 14:28:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AD368D0001; Fri, 19 Mar 2021 14:28:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64E746B007D; Fri, 19 Mar 2021 14:28:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 459366B0078 for ; Fri, 19 Mar 2021 14:28:13 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 06E1F181B04A2 for ; Fri, 19 Mar 2021 18:28:13 +0000 (UTC) X-FDA: 77937458466.21.D6BDE10 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 286192000397 for ; Fri, 19 Mar 2021 18:28:07 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id a1so13167924ljp.2 for ; Fri, 19 Mar 2021 11:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J6QHzWANXCm1SDgro0BN9kWI3qVUYrxfC5IeHWzOdDc=; b=XqMgT1C3COSq8U0uhLfZF1mhN+0leCRVgDQhdv8f8qYUTjYZFkdlVp1g+NPwesMUKa JsQpDKs/Za+UNeYiBzYo8HP1CFQLtajyEoXfRF81DkEkNVOIIgjUCBWy1MX80ENSVCkX SL530kChb5osZtRBLpWvw8N5+gvxZGeyrDDCM59d4BEY1gs1U0rBIvZnhf9PLGQ5SBMK zIi+ZHtL1XM4fK41xmYGI8CC4+tACGhpXmrJ/pAKK+x/nARRgnsLIojbz4NP1O+eemjA jxso7E4lrbiR+wUzmv8K0FqpX/IXXW+lGPfHnIi87hHXo4ZU5Q/aSCuxzshQ81cGSzep KeKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J6QHzWANXCm1SDgro0BN9kWI3qVUYrxfC5IeHWzOdDc=; b=BdYMflL+0XWQBWm8/DgifP3afSc5qeO5bcSrM13wWVeMvs8PZ44pjJYjhZ8D1E7+aX g+f2IcXJlYpRRLU0PZLr3CcHP/Z8KAJ62XvpnGiaJs8qwpSuLTl96T4SySv3dvT8ZNfQ 0yXC55oFYqB2D/sfnBXDDHr51ILDT7tZsae5nWfzl9l+vrh7FnVDHvDIN0E/bXYFYF2E uCMjHjlit4btsuNZZ9AZH510b6oGVHpNyMcrlIf1lD+TQcSwXiTd2ZvQ5dGUpqGXz/Vr +D4f1kAv/Nn8eDBvgJH7yynWHkISsrZ0WhoUoNhyGrS4iL1kEiyRZXDdT/PVqefX3RU9 dF/g== X-Gm-Message-State: AOAM532PraPYxexW6JtLD2lxz3Tjtwin6+Eq61nGdC8WbqYVvFlgaP4W NkKDJo3G1gjFQUkppro/LWDw92qEHwYk58snY726rA== X-Google-Smtp-Source: ABdhPJxew8YLG9vvfoGt8TDHG4Oa+irPZ0uYV3KUM+TSwaAUGGWMwgveoUALHDKCGz63uOS0FEqG+GGwNBGu2vmSOUs= X-Received: by 2002:a05:651c:2c6:: with SMTP id f6mr1708421ljo.279.1616178486188; Fri, 19 Mar 2021 11:28:06 -0700 (PDT) MIME-Version: 1.0 References: <20210319163821.20704-1-songmuchun@bytedance.com> <20210319163821.20704-6-songmuchun@bytedance.com> In-Reply-To: <20210319163821.20704-6-songmuchun@bytedance.com> From: Shakeel Butt Date: Fri, 19 Mar 2021 11:27:54 -0700 Message-ID: Subject: Re: [PATCH v5 5/7] mm: memcontrol: use obj_cgroup APIs to charge kmem pages To: Muchun Song Cc: Roman Gushchin , Johannes Weiner , Michal Hocko , Andrew Morton , Vladimir Davydov , LKML , Linux MM , Xiongchun duan Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: h85exxxk5qpktct98usoeax5px3n5jq6 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 286192000397 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-lj1-f177.google.com; client-ip=209.85.208.177 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616178487-956582 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, Mar 19, 2021 at 9:39 AM Muchun Song wrote: > > Since Roman series "The new cgroup slab memory controller" applied. All > slab objects are charged via the new APIs of obj_cgroup. The new APIs > introduce a struct obj_cgroup to charge slab objects. It prevents > long-living objects from pinning the original memory cgroup in the memory. > But there are still some corner objects (e.g. allocations larger than > order-1 page on SLUB) which are not charged via the new APIs. Those > objects (include the pages which are allocated from buddy allocator > directly) are charged as kmem pages which still hold a reference to > the memory cgroup. > > We want to reuse the obj_cgroup APIs to charge the kmem pages. > If we do that, we should store an object cgroup pointer to > page->memcg_data for the kmem pages. > > Finally, page->memcg_data will have 3 different meanings. > > 1) For the slab pages, page->memcg_data points to an object cgroups > vector. > > 2) For the kmem pages (exclude the slab pages), page->memcg_data > points to an object cgroup. > > 3) For the user pages (e.g. the LRU pages), page->memcg_data points > to a memory cgroup. > > We do not change the behavior of page_memcg() and page_memcg_rcu(). > They are also suitable for LRU pages and kmem pages. Why? > > Because memory allocations pinning memcgs for a long time - it exists > at a larger scale and is causing recurring problems in the real world: > page cache doesn't get reclaimed for a long time, or is used by the > second, third, fourth, ... instance of the same job that was restarted > into a new cgroup every time. Unreclaimable dying cgroups pile up, > waste memory, and make page reclaim very inefficient. > > We can convert LRU pages and most other raw memcg pins to the objcg > direction to fix this problem, and then the page->memcg will always > point to an object cgroup pointer. At that time, LRU pages and kmem > pages will be treated the same. The implementation of page_memcg() > will remove the kmem page check. > > This patch aims to charge the kmem pages by using the new APIs of > obj_cgroup. Finally, the page->memcg_data of the kmem page points to > an object cgroup. We can use the __page_objcg() to get the object > cgroup associated with a kmem page. Or we can use page_memcg() > to get the memory cgroup associated with a kmem page, but caller must > ensure that the returned memcg won't be released (e.g. acquire the > rcu_read_lock or css_set_lock). > > Signed-off-by: Muchun Song > Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt