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=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL 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 5FFEFC433E2 for ; Thu, 27 Aug 2020 21:59:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0572A2080C for ; Thu, 27 Aug 2020 21:59:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IH12sAJg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0572A2080C 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 53D966B0002; Thu, 27 Aug 2020 17:59:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C7246B0003; Thu, 27 Aug 2020 17:59:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 367D66B0006; Thu, 27 Aug 2020 17:59:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 19DE46B0002 for ; Thu, 27 Aug 2020 17:59:04 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CC3C04403 for ; Thu, 27 Aug 2020 21:59:03 +0000 (UTC) X-FDA: 77197714566.18.use62_320f18b27070 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 959CF100EC67D for ; Thu, 27 Aug 2020 21:59:03 +0000 (UTC) X-HE-Tag: use62_320f18b27070 X-Filterd-Recvd-Size: 4763 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Aug 2020 21:59:03 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id t6so8144702ljk.9 for ; Thu, 27 Aug 2020 14:59:03 -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=rVBJKgtv1iibetL73LRoXtok8/V4hB+ZfdXFnvRXGf4=; b=IH12sAJg8v6bzG3oDO+EpY2xw6hug1HwrUC0SsDTCfrC590GxvUo5KAml9BPQ+MRlH AQC+MxY12YD1Q9Jlc7koXumjtj80Thyoi/1D7ry0RtVkS/ztATEE8Fc9/e4JbVQS3G2W QCjSur0oCdHdftsGdiJD9FqxuAzToRJRtHE7da6qN8lzUg07yb+hpLSfiWWBkjvpNK9o FuAuXhyy9KE/s5rOgDMHUICzE85Z4Sp8JO7Ng6FOCbgFvUxafHEVz9DJbb7Hf4QRPstZ fXxjUiLeXkaApdCevoO+YQp4j7ubJmzou2UAJhA4mKkO6so7smARy85wBfXiKl3D3Mmp MeRQ== 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=rVBJKgtv1iibetL73LRoXtok8/V4hB+ZfdXFnvRXGf4=; b=iAL7u5HtzOGk8ZynqGFZFrB5IUr/Wk1Do71WrTBLfmuAOA84XRvixxrTs0XXdK2bd2 NdcxKYOw+AsFeRgXxy3/WSpt8d4EvjT6RA2YMQfIFrjTELB/+rIN5bWxK0jUPn9TOfFq DsLTCWckFUAEHnV6mRl+7fGwOPHH84FrqZwxEemID6O9I5CxfFAqkLFUxZFR4qhfv56c 8HMpnyDoLRJ2/g/NHk7J8612ajlL0d/24m26ACe17GqH1eVE34XzV7IPK2zvTVpCf21v VlPmLgEyT/8cz/adzdrgI8WEc3B/eIeK0/7F/YipUsUXKrc5kZTPGaOqDTqgIgtwK98W Gxmw== X-Gm-Message-State: AOAM5312ZjZSKpb3o1WiAT4dG99PBDOpu/+0wcfYNc13eKJLgi0qiyZI lZkmU7dEQkd9wL6ey//cy3bGVPBQWHzmayZkXrI6Qg== X-Google-Smtp-Source: ABdhPJzOo9PgEobHK8X5GAiYkmGBf8E1YvBdOfP74zzNTqV3ejOIMe30xqY6sCRKr0JbCmCXQ9JDUfF9jzJtV3dD67E= X-Received: by 2002:a2e:2a04:: with SMTP id q4mr9882666ljq.192.1598565541451; Thu, 27 Aug 2020 14:59:01 -0700 (PDT) MIME-Version: 1.0 References: <20200827175215.319780-1-guro@fb.com> <20200827175215.319780-4-guro@fb.com> In-Reply-To: <20200827175215.319780-4-guro@fb.com> From: Shakeel Butt Date: Thu, 27 Aug 2020 14:58:50 -0700 Message-ID: Subject: Re: [PATCH RFC 3/4] mm: kmem: prepare remote memcg charging infra for interrupt contexts To: Roman Gushchin Cc: Linux MM , Andrew Morton , Johannes Weiner , Michal Hocko , Kernel Team , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 959CF100EC67D X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000223, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Aug 27, 2020 at 10:52 AM Roman Gushchin wrote: > > Remote memcg charging API uses current->active_memcg to store the > currently active memory cgroup, which overwrites the memory cgroup > of the current process. It works well for normal contexts, but doesn't > work for interrupt contexts: indeed, if an interrupt occurs during > the execution of a section with an active memcg set, all allocations > inside the interrupt will be charged to the active memcg set (given > that we'll enable accounting for allocations from an interrupt > context). But because the interrupt might have no relation to the > active memcg set outside, it's obviously wrong from the accounting > prospective. > > To resolve this problem, let's add a global percpu int_active_memcg > variable, which will be used to store an active memory cgroup which > will be sued from interrupt contexts. set_active_memcg() will *used > transparently use current->active_memcg or int_active_memcg depending > on the context. > > To make the read part simple and transparent for the caller, let's > introduce two new functions: > - struct mem_cgroup *active_memcg(void), > - struct mem_cgroup *get_active_memcg(void). > > They are returning the active memcg if it's set, hiding all > implementation details: where to get it depending on the current context. > > Signed-off-by: Roman Gushchin I like this patch. Internally we have a similar patch which instead of per-cpu int_active_memcg have current->active_memcg_irq. Our use-case was radix tree node allocations where we use the root node's memcg to charge all the nodes of the tree and the reason behind was that we observed a lot of zombies which were stuck due to radix tree nodes charges while the actual pages pointed by the those nodes/entries were in used by active jobs (shared file system and the kernel is older than the kmem reparenting). Reviewed-by: Shakeel Butt