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=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6BDD6C56201 for ; Sat, 21 Nov 2020 02:52:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9D1122403 for ; Sat, 21 Nov 2020 02:52:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="oqddmQSa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9D1122403 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 3B1726B005C; Fri, 20 Nov 2020 21:52:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 33B6B6B005D; Fri, 20 Nov 2020 21:52:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 203E56B0068; Fri, 20 Nov 2020 21:52:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id D90986B005C for ; Fri, 20 Nov 2020 21:52:32 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7DAC78249980 for ; Sat, 21 Nov 2020 02:52:32 +0000 (UTC) X-FDA: 77506902144.02.fruit22_3b13be527350 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 5690E10097AA1 for ; Sat, 21 Nov 2020 02:52:32 +0000 (UTC) X-HE-Tag: fruit22_3b13be527350 X-Filterd-Recvd-Size: 4610 Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Sat, 21 Nov 2020 02:52:31 +0000 (UTC) Received: by mail-pl1-f195.google.com with SMTP id b3so5860257pls.11 for ; Fri, 20 Nov 2020 18:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8mnAmGJVt0wk6lg3SP3cGYFCzdDtUly5uoisYFOO9NU=; b=oqddmQSaU7WxHgpLmUVJ3J/xq9Qc7OBKmNm7a0BKlSQr3MoqAomFOFFsLIsIw6DJq3 /QHzlkkasHDOo3v4171XEcXqb3a4lYFisi9DNc+B3mNU/KYq+xci3EVlzL3wfKqzm2lb uQEJKprdNpnnkzxfAXTalB0uBbULuaa0vMmo8/JeNss5QWEHB9ikM+QGfnDR7bIIyQNB b8FnDaVuiwv/cSB3BgeqXYwOZxYd8Giwiyfv8Ddc5Jd+tmCsE5yiCaEgavHZe5rdkw1G u74/rBpKLHY2jTrgzCld1FTwH4l4/9M4X5tRT0dJRyCb9/mrQQ8rybAkPGry71TWvA+s dpyg== 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:references :mime-version:content-disposition:in-reply-to; bh=8mnAmGJVt0wk6lg3SP3cGYFCzdDtUly5uoisYFOO9NU=; b=hJzUp7u9PvZjKxivAhZNAxX5Wyl2g5b1IzZ7vNRvQ9D0OGHgtGdn5UjzwCDTj+mqLa 8txh2ROjVb5ufucvsJ0ARmXTM+ro1P282Nbw7z8Xq6BRQxy61LUrAXyU4DSeeEPhgMeS cdGv/bDWy6D1b/vrQohyAr/8GiSSmrLNY+jl5WLOwwqA9lflLDQbeC+jEy4BjZuKMvdq m9j+MISmgN6rGxuTpjFXPKo1n6FNrO+gLK/vDYo1vIi+DjlGHDpqNvtwdsuy2YU90T2k FAsTvMJQzSPBeVrk50GY3bHOufL3pPxDW5isVjfWjJ81r0Atg9wimUQ0awn44NnrB1zV BlCg== X-Gm-Message-State: AOAM530HkY7SKGYjPS3ToC3gfq1ROaOkP+xzEZnAFA8xZ3CrQY8fx9FI h/Go2g2YBWzXNenq0UMAlXs= X-Google-Smtp-Source: ABdhPJwrc478tMIxFH4OkcAptTBlTCM05uMFT4s3vs8gHDP9iAVDcZEGToVd5Fs2EDy3HYaVV9Ze9A== X-Received: by 2002:a17:902:8691:b029:d7:e0f9:b1b with SMTP id g17-20020a1709028691b02900d7e0f90b1bmr16912308plo.37.1605927150967; Fri, 20 Nov 2020 18:52:30 -0800 (PST) Received: from ast-mbp ([2620:10d:c090:400::5:501]) by smtp.gmail.com with ESMTPSA id h7sm5203491pgi.90.2020.11.20.18.52.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Nov 2020 18:52:30 -0800 (PST) Date: Fri, 20 Nov 2020 18:52:27 -0800 From: Alexei Starovoitov To: Roman Gushchin Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, andrii@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH bpf-next v7 32/34] bpf: eliminate rlimit-based memory accounting infra for bpf maps Message-ID: <20201121025227.dypweojhaz7elwb3@ast-mbp> References: <20201119173754.4125257-1-guro@fb.com> <20201119173754.4125257-33-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119173754.4125257-33-guro@fb.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000378, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 19, 2020 at 09:37:52AM -0800, Roman Gushchin wrote: > static void bpf_map_put_uref(struct bpf_map *map) > @@ -619,7 +562,7 @@ static void bpf_map_show_fdinfo(struct seq_file *m, struct file *filp) > "value_size:\t%u\n" > "max_entries:\t%u\n" > "map_flags:\t%#x\n" > - "memlock:\t%llu\n" > + "memlock:\t%llu\n" /* deprecated */ > "map_id:\t%u\n" > "frozen:\t%u\n", > map->map_type, > @@ -627,7 +570,7 @@ static void bpf_map_show_fdinfo(struct seq_file *m, struct file *filp) > map->value_size, > map->max_entries, > map->map_flags, > - map->memory.pages * 1ULL << PAGE_SHIFT, > + 0LLU, The set looks great to me overall, but above change is problematic. There are tools out there that read this value. Returning zero might cause oncall alarms to trigger. I think we can be more accurate here. Instead of zero the kernel can return round_up(max_entries * round_up(key_size + value_size, 8), PAGE_SIZE) It's not the same as before, but at least the numbers won't suddenly go to zero and comparison between maps is still relevant. Of course we can introduce a page size calculating callback per map type, but imo that would be overkill. These monitoring tools don't care about precise number, but rather about relative value and growth from one version of the application to another. If Daniel doesn't find other issues this can be fixed in the follow up.