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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 E8F72C282D8 for ; Fri, 1 Feb 2019 13:40:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B72F521872 for ; Fri, 1 Feb 2019 13:40:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="KbNJa3Qd" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730082AbfBANkd (ORCPT ); Fri, 1 Feb 2019 08:40:33 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:32883 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727008AbfBANkd (ORCPT ); Fri, 1 Feb 2019 08:40:33 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A8AA61729; Fri, 1 Feb 2019 08:40:31 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Fri, 01 Feb 2019 08:40:32 -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=ESKR3DyG4XJ32rCUARTQDcmfoWWdtzrFN/WUNZyTo /o=; b=KbNJa3QdD1JaPnqpudVxyt2kk/ipnxxjwQ2MFkYj/AXWtlMXRGkJPsMYK guo0JbSkXe8CUy9xmi6l33jSGqnLONQRs9+arKmWrqxvQCeh49F6psGnsGmufkZY lHZ3tKLaWC8o2vDxTcOhWFoj0sR1l3f/516uWwFFxpFYcKHNZDrpok1LK08YT8U0 tCnj4RKTfL+JujFkQgWTdrt1+aJKR8dPlvtySnRxfM7U11i9qrMZYrgogNz8EyeQ E/pzozIYFJAEJ8wa5XwECrEn78rKVIvcr6fesAsRvHgN/8KKzk9qlypD1THZvF0H fmkVW1q5Jop4KVikoFxbCKsofE4hw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjeekgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof hfufgjffesthejredtredtjeenucfhrhhomhepofgrrhhthihnrghsuceomheslhgrmhgs uggrrdhltheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsehlrghmsggurgdrlhhtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4C6EB9E19D; Fri, 1 Feb 2019 08:40:30 -0500 (EST) Message-Id: <1549028430.1478776.1648575992.104E2731@webmail.messagingengine.com> From: Martynas To: Jakub Kicinski Cc: netdev@vger.kernel.org, ys114321@gmail.com, ast@kernel.org, daniel@iogearbox.net, Yonghong Song MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 References: <20190131093801.32220-1-m@lambda.lt> <20190131120407.3ebaee11@cakuba.hsd1.ca.comcast.net> Subject: Re: [PATCH v2 bpf-next] bpf: add optional memory accounting for maps In-Reply-To: <20190131120407.3ebaee11@cakuba.hsd1.ca.comcast.net> Date: Fri, 01 Feb 2019 15:40:30 +0200 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jan 31, 2019, at 10:04 PM, Jakub Kicinski wrote: > On Thu, 31 Jan 2019 10:38:01 +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". > > What should happen for no-prealloc maps? I wanted to be consistent with "bpf_map_precharge_memlock". So, as such map elements are not charged against RLIMIT_MEMLOCK, I haven't enabled accounting for them (yet). > Would it make some sense to > charge the max map size to the user and not each allocation? Hmm, but that would not reflect a real memory usage, and it could potentially lead to some troubles. E.g. a process with tight cgroup mem limits gets OOM'd because we have pre-charged for what it actually doesn't use. > Or > perhaps remember the owner to be able to charge the data path > allocations which don't happen in process context as well? In use cases I am aware of all map updates happen within the same context, i.e. in the same cgroup. So, that cgroup becomes the "owner" of the allocations. Another issue is when we pin a map (regardless whether it was prealloc'd or not). In this case, if a process which created the map gets restarted and continues to use the map, then it is not being charged. But as long as the process runs in the same cgroup, it should be fine.