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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1939C433EF for ; Thu, 30 Dec 2021 19:06:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F2036B0071; Thu, 30 Dec 2021 14:06:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A0F06B0072; Thu, 30 Dec 2021 14:06:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0414B6B0074; Thu, 30 Dec 2021 14:06:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id E63146B0071 for ; Thu, 30 Dec 2021 14:06:27 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9D1108249980 for ; Thu, 30 Dec 2021 19:06:27 +0000 (UTC) X-FDA: 78975391614.16.CC9EA66 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf31.hostedemail.com (Postfix) with ESMTP id E43E920002 for ; Thu, 30 Dec 2021 19:06:06 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id t14so13592867ljh.8 for ; Thu, 30 Dec 2021 11:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2njUeTmOSXQ9oVKtPT8JUEx/StHcUEgojYN5cLkfSjY=; b=ZM8WvwPrv4jn2BKTcGXKjPqPB+DwjejlfUGS3gZPS0W045tepA4ylYeFNNBI6V11UJ 6EktwV7UeyEAGvNGtCRPMr2pPJ/yvgsH1xe3LQotuffsxB4VUEQk5Ei3UdXJVOYrduA+ FmMTkFTDkD9ywNpH7F9FOKxsKNpll/9EzdIJ5nnHsWxUSaJ8nrMNaGne8jLR2LzJg633 3vLlrPfI09PKm0sM16Iddw3gYA2hw8qnO9KI7KrumUEnIS1WWem9n5x5yq5e3PkL09iz zdx6PIAKhBhQIWo7meuPwLi//37SGfjzGIvxEeJ/zFuogwzztB0tQNlaK0OgN6CIwvW0 ZPTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2njUeTmOSXQ9oVKtPT8JUEx/StHcUEgojYN5cLkfSjY=; b=oHRMlN546Yf6pwQ5leRf9HPYV7+XeGhFKjmG43+xgiE4pQrN721DMIXygyOhF50kyn rbUorDEtXnkG2Vrv5MJD8jsY1vrd0zQaUpAy1q+V5GXxvkZ/8MgLagKJ0YJXIro+388B Nz3dbHyEND+9AiKrnFwIX9mKob71ISM30mCGc9Tqlz15WlEctUE2TMoJ8Dub0AkVwsiv IZoS4v9Xnd9Mrs5cWaKhWjuxneOasFnE3NWD2PvrV0e49dZbN53B50iT+3HBGnDDQD4Y tGXPn83+dvGReGQEcp6q4mhhHQ7wmRC/GEuGR/sRw8ehfYS1eaPlBHORGv5YP4JFAVri ubdA== X-Gm-Message-State: AOAM533woYCqCB1qwMhpLRpx2KUZlQJLN7HAMlv6G8flNk6eYRypGxJP tiu5DjyOTNmMH9LBo8uG26qVuodvNxA3x8nAXwQMnQ== X-Google-Smtp-Source: ABdhPJyRHsAS7y1biDeCD6kEm0K80HkFw5MoFDckjlmT1t4EDPGqsr5bzllsf+UL1XEhQQFGG61Zd1FJTe4e27CO1js= X-Received: by 2002:a05:651c:1790:: with SMTP id bn16mr27944310ljb.475.1640891185477; Thu, 30 Dec 2021 11:06:25 -0800 (PST) MIME-Version: 1.0 References: <20211222052457.1960701-1-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Thu, 30 Dec 2021 11:06:14 -0800 Message-ID: Subject: Re: [PATCH v2] memcg: add per-memcg vmalloc stat To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Muchun Song , Andrew Morton , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E43E920002 X-Stat-Signature: fyksbwiwguojdk6ix8rshcif39fpkk73 Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZM8WvwPr; spf=pass (imf31.hostedemail.com: domain of shakeelb@google.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1640891166-760957 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: Hi Michal, On Mon, Dec 27, 2021 at 2:48 AM Michal Hocko wrote: > [...] > > atomic_long_add(area->nr_pages, &nr_vmalloc_pages); > > + mod_memcg_page_state(area->pages[0], MEMCG_VMALLOC, area->nr_pages); > > > > /* > > * If not enough pages were obtained to accomplish an > > Is it safe to assume that the whole area is always charged to the same > memcg? I am not really deeply familiar with vmalloc internals but is it > possible that an area could get resized/partially reused with a > different charging context? >From what I understand, vmalloc areas are not resized or partially reused at the moment. There is some ongoing discussion on caching it but caching would also require updating the accounting part as well. Regarding the whole area charged to the same memcg, the only way it may get charged to different memcgs is if the process in which the allocations are happening is migrated to a different memcg. We can resolve this by traversing the pages in area->pages array (and use lruvec based stats instead). I did contemplate on making this a lruvec stat but decided to start simple and if we ever need per-node stat then we can easily move to lruvec based stats. Let me know what you think. thanks, Shakeel