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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED 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 808F0C282D8 for ; Fri, 1 Feb 2019 11:03:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 52E9C2082E for ; Fri, 1 Feb 2019 11:03:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="fUGSHqCp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730122AbfBALDw (ORCPT ); Fri, 1 Feb 2019 06:03:52 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:56459 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729924AbfBALDv (ORCPT ); Fri, 1 Feb 2019 06:03:51 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C3D621848; Fri, 1 Feb 2019 06:03:47 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Fri, 01 Feb 2019 06:03:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=92Bwy3F3qklMQ4b5UxPtriwdv3pfQaSOXIIha9z9L rE=; b=fUGSHqCpoWlgIBvmT8L2Kt/Ee95wgnkbuGjBaoIQpZ1zLmCjgF32Tub8I YiC0GCpzrbfK9NGFw5IBwuGU+IKkFl0PQ1SoUcOn/xTNvLoANlNA+fZezHgU2EhD 0V5NiW1VJur9FkTnpwZn8f0e8kgT5uoz/XZOGD2rSa9+Wr74Y9ZcdfFvRmMyGT88 2WAm2khA4K/4h+rmQQ5s1bH24+d6LlBn8MgpLOBkP06grhIJXP2/v+AxN5ms9jB2 bgfn41d8mJeN9kqLmnbxH2/x+nMIhjiH5O1O6iW3joBEgkd2MBXmQsn/xSW3irKb htj/aDVUx3IEOr/vc6AmqHxuvy53Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjeekgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof ffjgfufhesthejredtredtjeenucfhrhhomhepofgrrhhthihnrghsuceomheslhgrmhgs uggrrdhltheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsehlrghmsggurgdrlhhtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EEC559E19D; Fri, 1 Feb 2019 06:03:45 -0500 (EST) Message-Id: <1549019025.1438919.1648518112.6139DD49@webmail.messagingengine.com> From: Martynas To: Alexei Starovoitov Cc: netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, Y Song MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 Date: Fri, 01 Feb 2019 13:03:45 +0200 In-Reply-To: <20190131183531.d466egde46lywzwa@ast-mbp.dhcp.thefacebook.com> Subject: Re: [PATCH bpf-next] bpf: add optional memory accounting for maps References: <20190130140251.23784-1-m@lambda.lt> <20190131183531.d466egde46lywzwa@ast-mbp.dhcp.thefacebook.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jan 31, 2019, at 8:35 PM, Alexei Starovoitov wrote: > On Wed, Jan 30, 2019 at 03:02:51PM +0100, Martynas Pumputis wrote: > > Previously, memory allocated for a map was not accounted. Therefore, > > this memory could not be taken into consideration by the cgroups > > memory controller. > > > > This patch introduces the "BPF_F_ACCOUNT_MEM" flag which enables > > the memory accounting for a map, and it can be set during > > the map creation ("BPF_MAP_CREATE") in "map_flags". > > > > When enabled, we account only that amount of memory which is charged > > against the "RLIMIT_MEMLOCK" limit. > > > > To validate the change, first we create the memory cgroup "test-map": > > > > # mkdir /sys/fs/cgroup/memory/test-map > > > > And then we run the following program against the cgroup: > > > > $ cat test_map.c > > <..> > > int main() { > > usleep(3 * 1000000); > > assert(bpf_create_map(BPF_MAP_TYPE_HASH, 8, 16, 65536, 0) > 0); > > usleep(3 * 1000000); > > } > > # cgexec -g memory:test-map ./test_map & > > # cat /sys/fs/cgroup/memory/test-map/memory{,.kmem}.usage_in_bytes > > 397312 > > 258048 > > > > > > > > # bpftool map list > > 19: hash flags 0x0 > > key 8B value 16B max_entries 65536 memlock 5771264B > > # cat /sys/fs/cgroup/memory/test-map/memory{,.kmem}.usage_in_bytes > > 401408 > > 262144 > > > > As we can see, the memory allocated for map is not accounted, as > > 397312B + 5771264B > 401408B. > > > > Next, we enabled the accounting and re-run the test: > > > > $ cat test_map.c > > <..> > > int main() { > > usleep(3 * 1000000); > > assert(bpf_create_map(BPF_MAP_TYPE_HASH, 8, 16, 65536, BPF_F_ACCOUNT_MEM) > 0); > > usleep(3 * 1000000); > > } > > # cgexec -g memory:test-map ./test_map & > > # cat /sys/fs/cgroup/memory/test-map/memory{,.kmem}.usage_in_bytes > > 450560 > > 307200 > > > > > > > > # bpftool map list > > 20: hash flags 0x80 > > key 8B value 16B max_entries 65536 memlock 5771264B > > # cat /sys/fs/cgroup/memory/test-map/memory{,.kmem}.usage_in_bytes > > 6221824 > > 6078464 > > > > This time, the memory (including kmem) is accounted, as > > 450560B + 5771264B <= 6221824B > > > > Signed-off-by: Martynas Pumputis > ... > > @@ -49,7 +51,9 @@ static struct bpf_map *xsk_map_alloc(union bpf_attr *attr) > > > > err = -ENOMEM; > > > > - m->flush_list = alloc_percpu(struct list_head); > > + if (account_mem) > > + gfp |= __GFP_ACCOUNT; > > + m->flush_list = alloc_percpu_gfp(struct list_head, gfp); > > I think it's better to account this memory by default. > Extra flag during map creation is not needed. The main reason I made the accounting optional is that otherwise it could break existing BPF map users who have set cgroup memory limits. > There are nokmem and nosocket memcg boot options. > We can add one more to turn off accounting of bpf map memory. > Considering the suggested boot option, I'm OK with enabling it by default. Do you want me to add the option as part of this PR?