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=DKIMWL_WL_MED,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 C2F8EC169C4 for ; Thu, 31 Jan 2019 20:04:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92FBF20881 for ; Thu, 31 Jan 2019 20:04:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="l5w5dgcz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727232AbfAaUET (ORCPT ); Thu, 31 Jan 2019 15:04:19 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:46511 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726976AbfAaUET (ORCPT ); Thu, 31 Jan 2019 15:04:19 -0500 Received: by mail-qt1-f193.google.com with SMTP id y20so4855353qtm.13 for ; Thu, 31 Jan 2019 12:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=NJHN68dSUthTaAy6sDiOfDYyDV1Vz9zHBTnVjmIo/M8=; b=l5w5dgczEfx3rUbxSxOv5vs8z6lrUgJmF9bK8VJPuGparIdpZUybx9jIO9F69hY3L0 0XHSferKCu2ZAuYOY1qlXhyhOMFkjQVDE23wi2jb7VMNtuLK4OL5hK6jiQfIm/VaigON w9ZsU9CWFQS8du/BPwaRM1kjfw2S6/j6b1kDylLfRvq843I20gNw8Q3AG2Hf7LgeMrEL 0K4R5Q4XUCW0oc5pwrLTd8+Y2i9UFkZEU7/N0Vz8fNLeaHozPh4F1LrOxxQfj6F5u3uA neMUoZUGGtUDKQDf5H5yhfl2aVcVLaAfZfClwfASM67uwZnoT8vJNIcP/0NqbmcLBY9x JCbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=NJHN68dSUthTaAy6sDiOfDYyDV1Vz9zHBTnVjmIo/M8=; b=D+rC6qNuVRYeTFImyUxwYRVtGl3cRQoSPIpCYcUxa1VKzBaNsXMQdq0GOFy/PtiqW1 rPrwTrT4Nx7GLnvjv7+CsGA6GIoXlrGguOKOUDiK+THtH0kpfQFCepv6FqjPP5Py+j5r HutUMJfd8dW1q+wulZwFu3ZNxeVz/+tXFYUIbhjvlMqY/UOngMLfKO6ay38Eyoc9KX8G r4ZGZ7n5KZGtHPVyAjuamu00LFisu5Igrhqw/7l6TuKp7DIvGOkyuLKFKcZadfQaoTlB Qdcr8zR5RH/ZnXiGCjkq05xwWSSKKqJiLVUwqu0DxoN2QFOSfPs4DKWL8fQLFS6rS9+A pDpg== X-Gm-Message-State: AJcUukf1f++dK7EO9eucnY+rjInpihPwoasNxgYHFO9+cITxEENE/9Ze MgTWU2JlEXdbSMn3hTbErv9XBQ== X-Google-Smtp-Source: ALg8bN64hEqU6tk4Y0BW22VzADXSlF1zkkZvmj63r90kEGZkIQU/izoKHOlxF5qAaEQUhxlsJKJpJQ== X-Received: by 2002:ac8:21ce:: with SMTP id 14mr35203876qtz.306.1548965058361; Thu, 31 Jan 2019 12:04:18 -0800 (PST) Received: from cakuba.hsd1.ca.comcast.net ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id 128sm5537619qkn.77.2019.01.31.12.04.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 Jan 2019 12:04:18 -0800 (PST) Date: Thu, 31 Jan 2019 12:04:07 -0800 From: Jakub Kicinski To: Martynas Pumputis Cc: netdev@vger.kernel.org, ys114321@gmail.com, ast@kernel.org, daniel@iogearbox.net, Yonghong Song Subject: Re: [PATCH v2 bpf-next] bpf: add optional memory accounting for maps Message-ID: <20190131120407.3ebaee11@cakuba.hsd1.ca.comcast.net> In-Reply-To: <20190131093801.32220-1-m@lambda.lt> References: <20190131093801.32220-1-m@lambda.lt> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? Would it make some sense to charge the max map size to the user and not each allocation? Or perhaps remember the owner to be able to charge the data path allocations which don't happen in process context as well?