From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f53.google.com (mail-yx1-f53.google.com [74.125.224.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67F2331A7EA for ; Mon, 18 May 2026 23:26:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779146775; cv=none; b=Dq4KjA38sUmAOLqOYIqDqk8S+uzL6vuMl4plbG8Db3TEGet90mfGPr6rp8j2RMKnbN1w5K3wIDHbNiy8hgfxsFPqL+kI5XyJqW+bTAaP/nDxTML9zsrXH0V7UaEeY4W2YdKfedCg/pM/iudGvlA24fbgxcZWLhKPIDW3ehvVOE0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779146775; c=relaxed/simple; bh=0kYTwvcQTSXqGCDcUvwL/fysNGrf0hmcI8+XhRcCZRQ=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Yg13DPKepRlLU8H42sxCz+L+QU+UMdZWhpOZ/f5D+Q4onjYUUpu+8N+1ex/iC5fRrkeDv++wjdJav6itzQ5rO4GrM8I8xxE1D+WR36wgoNi4K/sy5Sw2iug6w1+OqWcbf29cbFYQRGAk6gWoWGdWVZlv7xdRaAKVbK/qusHj0yY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YS2i8Cme; arc=none smtp.client-ip=74.125.224.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YS2i8Cme" Received: by mail-yx1-f53.google.com with SMTP id 956f58d0204a3-651c5d525f6so2945104d50.3 for ; Mon, 18 May 2026 16:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779146773; x=1779751573; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eJpF8zNQx3fuLJ61e34VmvRInkcEmUUj8JXY5zhxM5M=; b=YS2i8CmeIMKZGmw1wt3gOYQOO/ga3y/EioMEEgV6o4U1uEpymU3ZGD3HX+UgW1p8zB JzpjskpL3N/4ijrI/prJ+SGGhVM4PoQfmwuxNOeO/cnMJv8wNvxA4QLL4ADq03NQdDIz nn4tVtMCQs2ZV1R3BAGd2wKFoeAC9pY/vueKnRNLLW61zB1IJ5gGFIuZqahz5UJ73g0P kyqDJkMVKJYsq1ZXY46iswuXnjzeai5/v5Z6whfe8GNmQeytEPiIYo4fiodukvUrwxq6 jycrPsGrGHbNGHQelkDfjnTYleC3RepBrP7GjYA5KaQiNh8MlrqH3uz8eli4UMUJ7T4d fOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779146773; x=1779751573; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eJpF8zNQx3fuLJ61e34VmvRInkcEmUUj8JXY5zhxM5M=; b=axGxpSv7zYnIetmOOuP2pAZocYJ+me9wTGzV2GmzsC/d09ztwYjC2DjPDWptMbKB+/ nc05UPMCKGSK+gWoCCNxGhcLNTRW9B/6YwKKLfztqsv/bmCckyy7R1F1N7Nq4VchGHam FwHxcOlfgySKO2U3JvJGOcngW8USivK4FJYopvjE7/jffyCsSoaB0k1qTpNQ4iW/7DsD ei/nQ8GlU/QnEUymMCVfyvY62ydvXPkAj5WA7PPGlaH0HJRh5Mud0zR+Cuq0NLORidwK sl4bf0D2va4eCJvFJ7r9S2rtJz8n6gYfff+GmunT6Du92rNJ+0/jGazNEMNla8h6SngN DIuQ== X-Forwarded-Encrypted: i=1; AFNElJ/c+UAJenT2qN51jOkOy3qpduraJRGbEVJD9M5wY+B/I8f1M7FR4cAtIbLUftEaAaDEP/F5USi/kLM09+Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzjG6qOBuDnNdmlzIDb89Wd94B/kfk3CGRrffNAenx4IebCYCiQ EtqBIqCYF+gp5c77kJTJVfIfRjYHSKoW1ZbS0WuBTqbU78R2NqEED/D8 X-Gm-Gg: Acq92OEqfQxQHxVWUXp6+eJ58A8/r0EE0zrOVyGyczkaRtSg92jHBK+TqsliZuB4f+i Y4x049NCHO7HEnSyqYgKH0KlUVgqjtNhdVF1LBSsIUiYlukPuTv9qOdATqT7vdfDHN2pNSc5z9h fb0kYZaObDKEeeJSrnodjo1CdjzbW0lCRo9wPiQB8DQOLkwJXHd7BeUk8vpA2SrAevto66dcL/w 4deTLNmrE++7wukE3StObjlyA85AG+ptmI8n+m1WA9XNLitK22TL44S4a4kHfND/ZHtNYZ5DO/T AnAHVZD9JW2P8G3W7Ix8b7e3T3435IL82q1qXc0HUZfrxfemjjirfPDFhgKEF63v2sKETqOZXwl TlPiFiGvi3licZJUzeTxNRUP0LDzgtlJCX4ixK4MXH46cpKbl2CyVJjXKeZu+AlDtR5LJFVe0mR gCoD8mfemuh+P3R7Bzl5w1Qi2NhBzZnZICAOqfoRQuj2cDOMmtoljmd8LXmHofH63Wq7W2S3TJH YyFd2ctvsBd8Dt1CQ== X-Received: by 2002:a05:690e:14c9:b0:65e:438e:c025 with SMTP id 956f58d0204a3-65e438edademr10259078d50.19.1779146773245; Mon, 18 May 2026 16:26:13 -0700 (PDT) Received: from localhost ([2a03:2880:f806:52::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-65e0db0aa51sm7022713d50.12.2026.05.18.16.26.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 16:26:12 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 18 May 2026 16:26:11 -0700 Message-Id: Cc: "David Vernet" , "Andrea Righi" , "Changwoo Min" , "Alexei Starovoitov" , "Andrii Nakryiko" , "Daniel Borkmann" , "Martin KaFai Lau" , "Kumar Kartikeya Dwivedi" , "Catalin Marinas" , "Will Deacon" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "Andrew Morton" , "David Hildenbrand" , "Mike Rapoport" , "Emil Tsalapatis" , , , , , , Subject: Re: [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages From: "Alexei Starovoitov" To: "Tejun Heo" , "Peter Zijlstra" X-Mailer: aerc References: <20260517211232.1670594-1-tj@kernel.org> <20260517211232.1670594-8-tj@kernel.org> <20260518072042.GP3102624@noisy.programming.kicks-ass.net> In-Reply-To: On Mon May 18, 2026 at 12:51 PM PDT, Tejun Heo wrote: > Hello, > > On Mon, May 18, 2026 at 09:20:42AM +0200, Peter Zijlstra wrote: > ... >> Should this really be part of scx rather than be part of the bpf-arena >> thing proper? > > It's just a layer on top of arena. If bpf folks are okay with it, I don't > see why it can't be a common utility thing on the bpf side. Well, this gen_pool based allocator of arena memory is a temporary hack. It's ok for rare allocation like in this at scx init time, but not suitable for active arena management. We don't need to expose it beyond scx. Having said that the fast and generic allocator for arena is definitely nee= ded. This break through with scratch page and bpf_arena_handle_page_fault() cannot be overstated. It is a huge improvement for kernel <-> bpf interacti= on. Not only kfuncs can now read arena without ugly __get_kernel_nofault(), but we can reuse mm/slub.c to manage arena memory! The key idea is simply this: get_freepointer() { if (s->flags & SLAB_BPF_ARENA) return (void *)(s->arena_kern_vm_start | (u32)(unsigned long)ptr); } I'm sloping a prototype.