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 D0676C48260 for ; Thu, 8 Feb 2024 06:26:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 222086B00A1; Thu, 8 Feb 2024 01:26:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E7336B00A3; Thu, 8 Feb 2024 01:26:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC6656B00A5; Thu, 8 Feb 2024 01:26:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C55046B00A1 for ; Thu, 8 Feb 2024 01:26:31 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A78C8A0915 for ; Thu, 8 Feb 2024 06:26:31 +0000 (UTC) X-FDA: 81767652582.03.4F88388 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf02.hostedemail.com (Postfix) with ESMTP id D8B9A8000B for ; Thu, 8 Feb 2024 06:26:29 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZXlNYzFg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707373589; 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=Yg5N2eIHVjcFb6EdgGwasaePa68HmUdXgO4Zy+pbjUU=; b=P0nSKmuegbOMZ+VT2tU+MHPf4bFKiUXhYZo3QfcMbvbmheoM+z8Q6f8GwbTodKX+JEtsfO W2EDuLPSCOGjlicLFEsc44QrKkhJ7iRSeUX0o2WS9dWBccYZTNVogptxt2w4330ilTM6Ph X44uWVm+/0LCtMBnxMxwEQM+4drJTHA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZXlNYzFg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707373590; a=rsa-sha256; cv=none; b=ftAWk7SAYwEgpDFpaSmPW/isYr/Vrf07NQVuq5L3dfcNoK0AHx18gUIA/KmM+dLliIux98 YaX9Uw8iGRgjwXRzxes3gmbGOWGz0jkH/Usg7X331stLuzTztpqFoiy41qY+Wp4ON0hsvq W/76QKcNKpaVXfBCHXVVZtKubJUvlII= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4101eb5a115so10007535e9.1 for ; Wed, 07 Feb 2024 22:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707373588; x=1707978388; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Yg5N2eIHVjcFb6EdgGwasaePa68HmUdXgO4Zy+pbjUU=; b=ZXlNYzFgbiZxB6c6d1R83yuxGNFXoQ9bLtkNCQXIQGdYD8qVbOrh6IIr7cL19dV8LQ cQmw5DSrk0sb2SZcL79rBgnPl3MtPpK+S/dlCo0/kGiIKh5CTf9XQDQg/hd57x80RrDa WSSPnJKcaTZyo9kilfZWE+VwBrirrbAVMtwji97obDXdGuNamsORz+4HQR/NAvas6sFj lwOaKgzo9HPKcfhVcMQ7mOl+b+fE+lDoG2WYH3SQAy9918pUbC9uY73aUDznz2ICyS6B 9bJAixZkgelEZmBBg3L5L/XZKmmllCRJwK1EQI/Vg8ioJuaAUptHI9I76xEGfB3QAOXa pzdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707373588; x=1707978388; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Yg5N2eIHVjcFb6EdgGwasaePa68HmUdXgO4Zy+pbjUU=; b=wU7CVQfz2X+1Gl75P+A0Updd86Jm4FH0eXzaBgcpUA/CWJzg2KDthJH/d47DZEX8jh QnGfQFDUprYHadljkas9awllBMW5OsECx2C3yPEN6bTpbnfBOn0y2qUYZPd17Pu0+HxX 5T+yCAxUcy6aQRQDOIMFrslOYWixSU1oy6cRbrfffrRNJLVjiXacb3IO2dk/JjT7NGx+ QVHJXiulxdnwagH88bD8h2G2h5Wu9cVRUFrM8ZcQqVRRuiLGpeaRbOkeGSLUqteOpwN9 WWFf2hGt0MrpCoS1MABS/tHRnJRB4akLiIMWioM6hOa4XcTcLIeAPouFkqEkeuwsASOi oW8g== X-Gm-Message-State: AOJu0YxwsyZEsm5SVSQ74ksfUPDQ1eu2SMnKL6Vj1gIdHmVQXBBBnmoE PuqklDQjuu161mmrOrcIQ9ijui8SsWfRypLcK0om9uzrhYK4snthe0LdU9JN8pmIEcpWiGr+kLP daIQ5yLpfgzRh+Kmv7URdN2dJ/Fc= X-Google-Smtp-Source: AGHT+IEfuDDkWCOCdAV74FSgXyGdtuHKcvod6mNhhGMphYcOnx0Mk/aOkKB3hqQaHQnXW97bWlN7gtDzF/IDv711mvo= X-Received: by 2002:a5d:5265:0:b0:33a:fafa:8cdc with SMTP id l5-20020a5d5265000000b0033afafa8cdcmr4937349wrc.32.1707373588109; Wed, 07 Feb 2024 22:26:28 -0800 (PST) MIME-Version: 1.0 References: <20240206220441.38311-1-alexei.starovoitov@gmail.com> <20240206220441.38311-5-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 7 Feb 2024 22:26:16 -0800 Message-ID: Subject: Re: [PATCH bpf-next 04/16] bpf: Introduce bpf_arena. To: Barret Rhoden Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Johannes Weiner , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: r9ogjsoqf3oojx3xyqatdgjsoreqoaud X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D8B9A8000B X-HE-Tag: 1707373589-447915 X-HE-Meta: U2FsdGVkX18K+aETQcdg8b8Ohc9u6N4Av7g6m4tloDxkJv5WPfj7lkVDWOkLlgHC0cyJxdbdLtWbCZ1VxDSdjz3K+2JLsB3nl1heQV8Bq33aCCkRskPCuxE8m/k/uczE3z0I90845nxhitQpk+++2kDRV7OZShOxwIsmwzaDhVq9OKfd2POmcwzUIeF9JNz2t09le5y4dTJwK92Af4BCr9WX1jAx86SNUPq+OSWc92XJZZqMC+/lAI0MmcU9e3hhW9i4PdssG7e0dcxKCdiLKNK8rWD9YF+/GB4Tnasdm5i1mq0ICzyqUD0pM9glpPR/yPv2d56aGcQlPYwxj9S7/9Hn+SKmDmDuNiEdOwy6BVckEoMrQzzb+bFZjW6iiCq9Dvso7/ud5uLANrd/Dh7cdd+KpBgVZYr8k0QpibvmEgVrbNpjhAbWkypISKnRKkpgLgB5vfoaeHpJsUbXPevORzY6usCoghQFJNgfSpP5xMWk37niO1QA8E4vh3ujFblVcWHp3p6nMAyqIR1e3nx4JH6m3Y2nqWihJmthOL1u8mE8tL98VcWx+vF/VaszptZqEw6H/U9zfpO9L9u3/7SxDk2tJjZpWNkVAZSonFfxwUNz6ldR9vT/9nxr2TEGX9gTPb49YV2WBji7MtVw/tikXdRAipWX/x1bd3t1N8M3hLwoLx+wx/xrOq6NnvgRYV/2Nm4QcjrN6s/rvLbf4xkrsQ1uhxhu8FjiXRBIBSTljilXkFzQanXivCaiF56g6jIbh2zkd+1SC74Hut+cfsPSlYohLvDiw5O8WkZhVARV3Jh6jgVJAOcuQIrweKSoTRD1pBlnsg+vKq5MkqdrNUtunOsVrTp56re7yfzbRb3NE4KoR6ijn+Mainsxpp/B0AwY/VWZu7+dQm0nsZxmSSMsmJKPrY840sDlTf5+Lc62J4nQFQLZ3EbR+1piJR78waXGrAsPszaIjbRxMyp0ZS2 9l8svPwT U/fB1GrlHunJtolX98fL5pVYWky3jBoskhSyRHpLgU7bOjqRS1ym0SoqFnPh8/g5yOl98YFD46uqx6WkbsyBun19aWKSxAHylcO2zra58UmSjh0Ox/dmMv41nvNKKBmm1NyyUjOnxmikhrII4UMZ3V19wj3jppWZvzoFXxythKadZY3PJ/xJlMsVgxL1YtL/AZlc+EHfRtZuBzQ0UJk3vItaSrAfvZmVxnNz1qKhp8mezRmAx8TFGaY91zEHgulE+r9WBGg68/L/0UxAdV60SmRpTK3LBd5Y3QQcxCh3nl3yYx9PU/2aALvY9t7o5zcvE1rIBQ2a8aw/on/jV3pg9O4SVVg+nhyrY5SOIAbmrF61AxIDzCBwXtKW1FOcCMAMKAHAmUSV97Zey6MlUG9its7a7n4jBSyDRyEzS1lbE3HdDInUKXZNJSps0Aq8Kd4UjQVmGHR8HwqQBbYU1Yk1L7XVtx8Ki5je8vPpXkX0SM4Mb/Ea5D3UPa5oyZDOo9f2AFO6G X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 7, 2024 at 1:12=E2=80=AFPM Barret Rhoden wrot= e: > > On 2/7/24 15:55, Alexei Starovoitov wrote: > >> instead of uaddr, can you change this to take an address relative to t= he > >> arena ("arena virtual address"?)? the caller of this is in BPF, and > >> they don't easily know the user virtual address. maybe even just pgof= f > >> directly. > > I thought about it, but it doesn't quite make sense. > > bpf prog only sees user addresses. > > All load/store returns them. If it bpf_printk-s an address it will be > > user address. > > bpf_arena_alloc_pages() also returns a user address. > > Yeah, makes sense to keep them all in the same address space. > > > > > Kernel addresses are not seen by bpf prog at all. > > kern_vm_base is completely hidden. > > Only at JIT time, it's added to pointers. > > So passing uaddr to arena_alloc_pages() matches mmap style. > > > > uaddr =3D bpf_arena_alloc_pages(... uaddr ...) > > uaddr =3D mmap(uaddr, ...MAP_FIXED) > > > > Passing pgoff would be weird. > > Also note that there is no extra flag for bpf_arena_alloc_pages(). > > uaddr =3D=3D full 64-bit of zeros is not a valid addr to use. > > The problem I had with uaddr was that when I'm writing a BPF program, I > don't know which address to use for a given page, e.g. the beginning of > the arena. I needed some way to tell me the user address "base" of the > arena. Though now that I can specify the user_vm_start through the > map_extra, I think I'm ok. > > Specifically, say I want to break up my arena into two, 2GB chunks, one > for each numa node, and I want to bump-allocate from each chunk. When I > want to allocate the first page from either segment, I'll need to know > what user address is offset 0 or offset 2GB. bump allocate... you mean like page_frag alloc does? I've implemented one on top of arena: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/tree/tools/test= ing/selftests/bpf/bpf_arena_alloc.h?h=3Darena&id=3D36d78b0f1c14c959d907d68c= d7d54439b9213d0c Also I believe I addressed all issues with missing mutex and wrap around, and pushed to: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=3Dare= na&id=3De1cb522fee661e7346e8be567eade9cf607eaf11 Please take a look. Including the wrap around test in the last commit: https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=3Dare= na&id=3D01653c393a4167ccca23dc5a69aa9cf34a46eabd Will wait a bit before sending v2.