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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D511C32771 for ; Fri, 19 Aug 2022 14:31:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71DA38D0003; Fri, 19 Aug 2022 10:31:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A6548D0002; Fri, 19 Aug 2022 10:31:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 546EC8D0003; Fri, 19 Aug 2022 10:31:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3EEC48D0002 for ; Fri, 19 Aug 2022 10:31:48 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1087AA14B1 for ; Fri, 19 Aug 2022 14:31:48 +0000 (UTC) X-FDA: 79816581096.22.E57BE00 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf21.hostedemail.com (Postfix) with ESMTP id C14D11C001A for ; Fri, 19 Aug 2022 14:31:47 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id c4so2593824iof.3 for ; Fri, 19 Aug 2022 07:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=AjbWubpcUa9YQyhG2E/jmsWbUQjRwTtqNUg4iIKtN+8=; b=C6anqngy5zaJtJIkFBWXsltajPoLTr1rr1XPNtqI2RSKz6tGxTwn9hv98osC5GAcrY zpGwuCHoPTq2zMpxLs28lV+xuWvyk8qajrh/JQPe7p5uT3W4rkRZHAditnhqdrUwfS38 IfjbgFXacBkCtHtP2TrHUut2KKtO8Y88MshVC+e7vMgmvnpJBSUPRPsQhh/ja5P1xoDQ Dpkt52pVBkQzJMomL/X48MXR9g0U7bL7QMQLPmjbNpNtG7CcKpNEXB5Qt8h+oqFTJLRt 7SEvcA+anHsZdPxQhSEbB9RGorXmK8gLECE7+eu7xGf44hWiq9MRLS4m9QOEi6BYBWJA RNqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=AjbWubpcUa9YQyhG2E/jmsWbUQjRwTtqNUg4iIKtN+8=; b=dcQKlkSaNS+njbZdH8M7nFRwtwpZI6kFKwgz6ujUXLzsxX9iu5n4KwWicnhSl8rvSD JRpoq7wN5vQDNbAZQYI6BcrQMQS9JSS1GvLwKX87g5MPA67MPk1HmHfN9rhGB894//AX T8GR4zvvSCd3C/TDWnVNYjotMRspyWsFNR8rvnv19vnPTeFpzEkN9ooElrLdz+amx5FD d5KDyyXF//QMobB+VFxSWBCwI4GXKEm9ul3haoBrbHY4wp9mO6faC9YuWwBuDpb4ObeU tOj/1B7V2pdfnq9wuwU2Fv2L4iLNdTtmqns4yqaNAZWIAt3kXixqY4GXqjgPNAEmaHlG hl7w== X-Gm-Message-State: ACgBeo3348KcAltV/orVQJfBhNGqI9ecRQhbVCRidEwRSH3HMIST48Vs YYxoVms/MWXJR6PNv9OsGOXxQGSnXoDPo8BYbbI= X-Google-Smtp-Source: AA6agR6tC4Ut7gTSRB4ZYvcO8nQhbPvmaX07V2qlN6w9X0wA5ZRqEus3zAEtUGqOriIh/asA/sxCAc8EUx9gHr8KZwE= X-Received: by 2002:a05:6638:1394:b0:343:6ce7:2849 with SMTP id w20-20020a056638139400b003436ce72849mr3712899jad.231.1660919506896; Fri, 19 Aug 2022 07:31:46 -0700 (PDT) MIME-Version: 1.0 References: <20220817210419.95560-1-alexei.starovoitov@gmail.com> <20220817210419.95560-2-alexei.starovoitov@gmail.com> <20220818003957.t5lcp636n7we37hk@MacBook-Pro-3.local> <20220818223051.ti3gt7po72c5bqjh@MacBook-Pro-3.local.dhcp.thefacebook.com> In-Reply-To: <20220818223051.ti3gt7po72c5bqjh@MacBook-Pro-3.local.dhcp.thefacebook.com> From: Kumar Kartikeya Dwivedi Date: Fri, 19 Aug 2022 16:31:11 +0200 Message-ID: Subject: Re: [PATCH v2 bpf-next 01/12] bpf: Introduce any context BPF specific memory allocator. To: Alexei Starovoitov Cc: davem@davemloft.net, daniel@iogearbox.net, andrii@kernel.org, tj@kernel.org, delyank@fb.com, linux-mm@kvack.org, bpf@vger.kernel.org, kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660919507; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AjbWubpcUa9YQyhG2E/jmsWbUQjRwTtqNUg4iIKtN+8=; b=T8QgXfpxiJY2Hi5Lnkhf0p6PCAq3U/LXUTJaOTQKAXD79/IfSlNpcsaP32Ii0PD0+9X6g/ Ez0Etqgkt0DKi0aqeDsiKFM9077Csuj9rzfTXXbPTDMFeICnpO9ivmle+3K1s4i2hWj+K6 PUXUvQ7xSYogfJr4AfjhCQRpw4eHvfg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=C6anqngy; spf=pass (imf21.hostedemail.com: domain of memxor@gmail.com designates 209.85.166.68 as permitted sender) smtp.mailfrom=memxor@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660919507; a=rsa-sha256; cv=none; b=KhiHOwL6WsfrpluNi/m7apy3ie/npGTV+Jg20c2TVJcrTK/M8aGn668IsajD2cah3JYsdY H/CX9sUPIYMLT2+fmVRggRf9tiO1HbPJfYNbOJ0DxMmfQDRanv2pd/FDbY02VPLHXCNdGt f/SU+6itnBfs3sRGv3YGH+IpmbG19IQ= X-Rspam-User: X-Rspamd-Queue-Id: C14D11C001A Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=C6anqngy; spf=pass (imf21.hostedemail.com: domain of memxor@gmail.com designates 209.85.166.68 as permitted sender) smtp.mailfrom=memxor@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: pf8yafmq38uipg6ut81sf6quqejd8wqp X-Rspamd-Server: rspam10 X-HE-Tag: 1660919507-194758 X-Bogosity: Ham, tests=bogofilter, spamicity=0.083696, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 19 Aug 2022 at 00:30, Alexei Starovoitov wrote: > > Right. We cannot fail in unit_free(). > With per-cpu counter both unit_alloc() and free_bulk_nmi() would > potentially fail in such unlikely scenario. > Not a big deal for free_bulk_nmi(). It would pick the element later. > For unit_alloc() return NULL is normal. > Especially since it's so unlikely for nmi to hit right in the middle > of llist_del_first(). > > Since we'll add this per-cpu counter to solve interrupted llist_del_first() > it feels that the same counter can be used to protect unit_alloc/free/irq_work. > Then we don't need free_llist_nmi. Single free_llist would be fine, > but unit_free() should not fail. If free_list cannot be accessed > due to per-cpu counter being busy we have to push somewhere. > So it seems two lists are necessary. Maybe it's still better ? > Roughly I'm thinking of the following: > unit_alloc() > { > llnode = NULL; > local_irq_save(); > if (__this_cpu_inc_return(c->alloc_active) != 1)) > goto out; > llnode = __llist_del_first(&c->free_llist); > if (llnode) > cnt = --c->free_cnt; > out: > __this_cpu_dec(c->alloc_active); > local_irq_restore(); > return ret; > } > unit_free() > { > local_irq_save(); > if (__this_cpu_inc_return(c->alloc_active) != 1)) { > llist_add(llnode, &c->free_llist_nmi); > goto out; > } > __llist_add(llnode, &c->free_llist); > cnt = ++c->free_cnt; > out: > __this_cpu_dec(c->alloc_active); > local_irq_restore(); > return ret; > } > alloc_bulk, free_bulk would be protected by alloc_active as well. > alloc_bulk_nmi is gone. > free_bulk_nmi is still there to drain unlucky unit_free, > but it's now alone to do llist_del_first() and it just frees anything > that is in the free_llist_nmi. > The main advantage is that free_llist_nmi doesn't need to prefilled. > It will be empty most of the time. > wdyt? Looks great! The other option would be to not have the overflow free_llist_nmi list and just allowing llist_add to free_llist from the NMI case even if we interrupt llist_del_first, but then the non-NMI user needs to use the atomic llist_add version as well (since we may interrupt it), which won't be great for performance. So having the extra list is much better.