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 14E8AC43334 for ; Mon, 4 Jul 2022 16:13:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F2D86B0078; Mon, 4 Jul 2022 12:13:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87BE16B007B; Mon, 4 Jul 2022 12:13:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 745626B007D; Mon, 4 Jul 2022 12:13:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6499D6B0078 for ; Mon, 4 Jul 2022 12:13:20 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 15993603EB for ; Mon, 4 Jul 2022 16:13:20 +0000 (UTC) X-FDA: 79649912160.31.3AA626E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 6B9F914000D for ; Mon, 4 Jul 2022 16:13:19 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id F099C1F91E; Mon, 4 Jul 2022 16:13:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1656951198; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/fboqFL4a8xWdGOZp/3ipc1cfDpcMeyzqyxT1wDWv/M=; b=O/2cG6sqm34p/4l090bCtOc/4h4kniOc4A7rps7hIDkRMxe2BdNs66TI47un+ifO423Ska Z8e8tjMOk2zHzDAaHJsAHlBeek4cYn3HOlMTS2na4n3+XGYEbwDLcmDhLBL9pQNUTKm432 lay7smnMYVGI5exyzlHN7ZyWJ0WFR4g= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1656951198; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/fboqFL4a8xWdGOZp/3ipc1cfDpcMeyzqyxT1wDWv/M=; b=VNtWl4AIuwsWmSxpVy8hPib9zNA15ZcGFUHYBMwEMQxH327eOrsL+xOoOS0Q2LLcYlJZ0h Q9up0a3iMlKIeNCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B9EB813451; Mon, 4 Jul 2022 16:13:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 9MWxLJ0Rw2LzCAAAMHmgww (envelope-from ); Mon, 04 Jul 2022 16:13:17 +0000 Message-ID: <8a160205-99fe-a632-aeed-6b59eadc2aa2@suse.cz> Date: Mon, 4 Jul 2022 18:13:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. Content-Language: en-US To: Alexei Starovoitov , Christoph Lameter Cc: Christoph Hellwig , David Miller , Daniel Borkmann , Andrii Nakryiko , Tejun Heo , Martin KaFai Lau , bpf , Kernel Team , linux-mm , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Matthew Wilcox , "Liam R. Howlett" References: <20220628170343.ng46xfwi32vefiyp@MacBook-Pro-3.local> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656951199; a=rsa-sha256; cv=none; b=B+RevTHNsa6MgrL4C5zPTXco0gp04tf9IxQHZ0lQ37WMuMeo7eubJQag1e97oDzdYBm7SF /LRUP5kQqVdOWLHOlkTuZgA73PFcl/d5KoPQ6yaRieZ2t/oBp8yNit2vpfDlcLPBH/U1UU YXJZ63jNiSJ2zzAA0EFAAVD/iIjXFek= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="O/2cG6sq"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=VNtWl4AI; dmarc=none; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656951199; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/fboqFL4a8xWdGOZp/3ipc1cfDpcMeyzqyxT1wDWv/M=; b=oSDJ/blNxF39aJQ58hrr36kb+sh/x8/Kg/nrVQGpKrm2I6ieYR5YJRWSoDfsw6Mb+12Lxi jA1xTLDMJzJRY2lVlYQOcn6pkbymXU/H+8DH0GG5ZzdTuh5GPnRV2qHZqTlUySvuD+ObB4 mlSpwQ6eML2XtAwPXt/NQkZP0plA750= Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="O/2cG6sq"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=VNtWl4AI; dmarc=none; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Rspam-User: X-Stat-Signature: 3nfca3ix1fur7a55t3kwe6gcmuhi897j X-Rspamd-Queue-Id: 6B9F914000D X-Rspamd-Server: rspam04 X-HE-Tag: 1656951199-138887 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/29/22 04:49, Alexei Starovoitov wrote: > On Tue, Jun 28, 2022 at 7:35 PM Christoph Lameter wrote: >> >> On Tue, 28 Jun 2022, Alexei Starovoitov wrote: >> >> > > That is a relatively new feature due to RT logic support. without RT this >> > > would be a simple irq disable. >> > >> > Not just RT. >> > It's a slow path: >> > if (IS_ENABLED(CONFIG_PREEMPT_RT) || >> > unlikely(!object || !slab || !node_match(slab, node))) { >> > local_unlock_irqrestore(&s->cpu_slab->lock,...); >> > and that's not the only lock in there. >> > new_slab->allocate_slab... alloc_pages grabbing more locks. >> >> >> Its not a lock for !RT. >> >> The fastpath is lockless if hardware allows that but then we go into more >> and more serialiation needs as the allocation gets more into the page >> allocator logic. Yeah I don't think the recent RT-related changes made this much worse than it already was. In alloc side you could perhaps try the really lockless fastpaths only and fail if e.g. the per-cpu slabs were empty (but would BPF be happy with that?). On the free side though you could end up having to move a slab from partial to free list as a result, and now a spin lock is needed (even before the RT changes), and you can't really fail a free... > On RT fast path == slow path with a lock. > On !RT fast path is lock less. > That's all correct. > bpf side has to make sure safety in all possible paths > therefore RT or !RT makes no difference. So AFAIK we don't right now have what BFP needs - an extra-constrained kind of GFP_ATOMIC. I don't object you adding it privately. But it's another reason to think about if these things can be generalized. For example we had a discussion about the Maple tree having kinda similar kinds of requirements to avoid its tree node preallocations always for the worst possible case. I'm not sure we can sanely implement this within each of SLAB/SLUB/SLOB, or rather provide a generic cache on top...