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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38BE2CCA47B for ; Mon, 11 Jul 2022 12:15:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231620AbiGKMPM (ORCPT ); Mon, 11 Jul 2022 08:15:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230051AbiGKMPL (ORCPT ); Mon, 11 Jul 2022 08:15:11 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 039314332D for ; Mon, 11 Jul 2022 05:15:10 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A6222227FB; Mon, 11 Jul 2022 12:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1657541709; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Nh7Cjgh1nIXP+UwTbrJCXYNeOJjUHlMFOdlb+pzeUDQ=; b=nVPskBYi7az3KFfHEr30XgLz83iUMuVIhwEgmOAX3YOCWb2clpxAVK0X5y0G6SW48eJkXn mvLM/VrQJl88YyQtRO4e1xHFx9hbF7Nw6QeCXkvuV8Afl8MrW+TtNxjfxaYBiiQcKQX+EV dF1B9pcF/J0DfiZmszoYKdl5onydFck= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 9E9182C141; Mon, 11 Jul 2022 12:15:07 +0000 (UTC) Date: Mon, 11 Jul 2022 14:15:07 +0200 From: Michal Hocko To: Shakeel Butt Cc: Alexei Starovoitov , Matthew Wilcox , Christoph Hellwig , "David S. Miller" , Daniel Borkmann , Andrii Nakryiko , Tejun Heo , Martin KaFai Lau , bpf , Kernel Team , linux-mm , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. Message-ID: References: <20220706175034.y4hw5gfbswxya36z@MacBook-Pro-3.local> <20220706180525.ozkxnbifgd4vzxym@MacBook-Pro-3.local.dhcp.thefacebook.com> <20220708174858.6gl2ag3asmoimpoe@macbook-pro-3.dhcp.thefacebook.com> <20220708215536.pqclxdqvtrfll2y4@google.com> <20220710073213.bkkdweiqrlnr35sv@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220710073213.bkkdweiqrlnr35sv@google.com> Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Sun 10-07-22 07:32:13, Shakeel Butt wrote: > On Sat, Jul 09, 2022 at 10:26:23PM -0700, Alexei Starovoitov wrote: > > On Fri, Jul 8, 2022 at 2:55 PM Shakeel Butt wrote: > [...] > > > > > > Most probably Michal's comment was on free objects sitting in the caches > > > (also pointed out by Yosry). Should we drain them on memory pressure / > > > OOM or should we ignore them as the amount of memory is not significant? > > > > Are you suggesting to design a shrinker for 0.01% of the memory > > consumed by bpf? > > No, just claim that the memory sitting on such caches is insignificant. yes, that is not really clear from the patch description. Earlier you have said that the memory consumed might go into GBs. If that is a memory that is actively used and not really reclaimable then bad luck. There are other users like that in the kernel and this is not a new problem. I think it would really help to add a counter to describe both the overall memory claimed by the bpf allocator and actively used portion of it. If you use our standard vmstat infrastructure then we can easily show that information in the OOM report. -- Michal Hocko SUSE Labs