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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 37DC6C56202 for ; Thu, 26 Nov 2020 17:13:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9BE1021D7F for ; Thu, 26 Nov 2020 17:13:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bNIV9vN0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BE1021D7F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EBD416B0070; Thu, 26 Nov 2020 12:13:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6F006B0073; Thu, 26 Nov 2020 12:13:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5DF06B0074; Thu, 26 Nov 2020 12:13:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id BD1F06B0070 for ; Thu, 26 Nov 2020 12:13:08 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 89D831EF1 for ; Thu, 26 Nov 2020 17:13:08 +0000 (UTC) X-FDA: 77527214856.30.print25_201291027381 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 719F1180B3C83 for ; Thu, 26 Nov 2020 17:13:08 +0000 (UTC) X-HE-Tag: print25_201291027381 X-Filterd-Recvd-Size: 5005 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Nov 2020 17:13:07 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id b17so3076459ljf.12 for ; Thu, 26 Nov 2020 09:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VpnUj0vwEBxW6p7ITczWY4IsgxvLvEJLYdLmcYXOZkU=; b=bNIV9vN0a4JsfmKqZ80aejvtZg4VlBh59eCSvINKkY7gI+B3p+OINaw1WT8TbCuYEp w9SieaelhASvFeb55DSGvdrvjXoa8lCwCqZCffodPp7944KO4zJpQSkdVpwDf5B6mmPd MmKveMlfHhcEnUbl1FMte4aJpELc8Wtt3ENVKEEVfMGk/tTXcmS+a84sk9XirGRBFa75 Pz/oTnxPeCwC9u/bNg8DJCn+qRvt7/gQRVVmn2X6jxWNyoVc8ddJy4TbAs/X3poYhsn3 bhlzF+ZVefYRNx2Hi7+3WG1KJ5joQFxklIMgsIEX/v4JUJ+/WE7VLGCtv0ZhEzJ4cHrj L04g== 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=VpnUj0vwEBxW6p7ITczWY4IsgxvLvEJLYdLmcYXOZkU=; b=uF1QQh/ABVO2Maa1E3G5g14f2Q49RCuP6r0HiWRrioYX9JfNc+UOtNRH1cZJFcxcnU HIOQz7SR70GITFulOWgUYQnAV8PoE2AE/+EehdP7EdQoJ4M/QXmudEBFSkLmRkSGO0/r GidLrCH2KFzWMbNKJY3UsBYUJp+sntvDPHLyKcKV3s6RuC6PCziy9qbnv9BFUhKHHJEW WogpCtzlCWOKg4xgdvFjc6N4pK9VKl6oROvEP6eKLO8PYfZDH1yQ/lyLN2ZC6QpkHs/n yQp1J9Q/CHJQjoHgJjNhdeNtQl6gA4PSOdiGzekQlWk6dhcmMf/B7x6ZMlLDJaebP7Al 6DRg== X-Gm-Message-State: AOAM53054BxfKgpGfIHKBRh6J4eucuy0UPXBlHjhbNWD5m+5MdSPDNca mXFgbV/Rp1To7RLJnIgHpQRHZZ0iYK4r+RNCBEg= X-Google-Smtp-Source: ABdhPJy3urs2BeAfWjkHI6bDf9nhnilb7OzdM0ndQotzW8xx/eFGnLcSx3/i/yka1xN40aF1n6yHdaWNpOKCmlEuXMA= X-Received: by 2002:a2e:9648:: with SMTP id z8mr1567183ljh.91.1606410786463; Thu, 26 Nov 2020 09:13:06 -0800 (PST) MIME-Version: 1.0 References: <20201125030119.2864302-1-guro@fb.com> <20201125030119.2864302-7-guro@fb.com> <20201126023000.GB840171@carbon.dhcp.thefacebook.com> In-Reply-To: <20201126023000.GB840171@carbon.dhcp.thefacebook.com> From: Alexei Starovoitov Date: Thu, 26 Nov 2020 09:12:55 -0800 Message-ID: Subject: Re: [PATCH bpf-next v8 06/34] bpf: prepare for memcg-based memory accounting for bpf maps To: Roman Gushchin Cc: Daniel Borkmann , bpf , Alexei Starovoitov , Network Development , Andrii Nakryiko , Andrew Morton , linux-mm , LKML , Kernel Team , Johannes Weiner , Tejun Heo Content-Type: text/plain; charset="UTF-8" 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 Wed, Nov 25, 2020 at 6:30 PM Roman Gushchin wrote: > > I did consider this option. There are pros and cons. In general we tend to charge the cgroup > which actually allocates the memory, and I decided to stick with this rule. I agree, it's fairly > easy to come with arguments why always charging the map creator is better. The opposite is > also true: it's not clear why bpf is different here. So I'm fine with both options, if there > is a wide consensus, I'm happy to switch to the other option. In general, I believe that > the current scheme is more flexible. I don't understand the 'more flexible' part. The current_memcg or map_memcg approach makes it less predictable. pre-alloc vs not is somewhat orthogonal. I've grepped through the kernel where set_active_memcg() is used and couldn't find a conditional pattern of its usage. If memcg is known it's used. I couldn't come up with the use case where using current memcg is the more correct thing to do. > In general we tend to charge the cgroup which actually allocates the memory that makes sense where allocation is driven by the user process. Like user space doing a syscall then all kernel allocation would be from memcg of that process. But bpf tracing allocations are not something that the user process requested the kernel to do. It's like another user space process tapped into another. Arguably when bpf prog is running the two user processes are active. One that created the map and loaded the prog and another that is being traced. I think there will be cases where bpf prog will request the kernel to allocate memory on behalf of the process being traced, but that memory should be given back to the process and accessible by it in some form. Like bpf prog could ask the kernel to grow heap of that process or trigger readahead. In such case current_memcg would be the right thing to charge.