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 931ACC48297 for ; Mon, 12 Feb 2024 18:21:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1EDF6B007E; Mon, 12 Feb 2024 13:21:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECEFC6B0080; Mon, 12 Feb 2024 13:21:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBE6A6B0081; Mon, 12 Feb 2024 13:21:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CC2E06B007E for ; Mon, 12 Feb 2024 13:21:40 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9A5241C12A9 for ; Mon, 12 Feb 2024 18:21:40 +0000 (UTC) X-FDA: 81783969960.02.8E973A4 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf07.hostedemail.com (Postfix) with ESMTP id BA92240022 for ; Mon, 12 Feb 2024 18:21:38 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bCgykix0; spf=pass (imf07.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707762098; a=rsa-sha256; cv=none; b=NWi6dGyzRlP32FhBrjPtLZHeoxLspW5NB+/nO0uK7W/LrZyeEN+dtNS5sJsdU+LBgfIjee nwT6Z9uKuJJMi0iMYQLB0WGi7/GDPqG1ErZmTPmVsycBHPmrm7S1UtWwx6Pcv4TD5i+rve 1BojKzwqwXHMSGmMz6qnS+LorB+bMGk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bCgykix0; spf=pass (imf07.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707762098; 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=0u/mnqYWI45lyZB60y3ICaYS3nY00uiM3qP2/Wq4tK0=; b=ngx1hYTyffwTQEJ28UcKRGw/3vqTY70oiQ4LALS59yd5h7JqJQliRMaW2F3XWBbXqrN0nR rHtw37gB+Y2G+6PNUPeXe8PG8rFSDnBSiQSvh8c+qJaTM5S6kSmh+gf66gdzkuOo+pNki9 7PU7y2qCU24o2Ysvr92O8vJwlelDFkI= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-33adec41b55so56864f8f.0 for ; Mon, 12 Feb 2024 10:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707762097; x=1708366897; 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=0u/mnqYWI45lyZB60y3ICaYS3nY00uiM3qP2/Wq4tK0=; b=bCgykix0peKSbzjhxZKA5ifQokgCu4yTX1NjRJG6zfxhxfTjUbDyRc1jHbIWZA+mkp m4oHpVKAGgD+2bA3x9KruCcouAXqRyIsa0HCCBzR/w2PQ3bjvGoYLDZNwLurZ2Rhj0WZ Plskd2QXmRu4+szikigFtDlxYiw349focJlSMd1TeMKwoXxNd02dbsSjymMJav8aUkTj KsEKu55jIzUcRUkMqnUVovktbON8z5BTdfY4DowfG4Lbg/EDz/lIAwbW73tP5FrUSo0G gIaWaeVPQJlM6ZGEb2ezHgs/kWhsfHlWUz6hwdObZVBJYGAnWvmqyuEgvnFO3n3Bm3TU 2LAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707762097; x=1708366897; 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=0u/mnqYWI45lyZB60y3ICaYS3nY00uiM3qP2/Wq4tK0=; b=pcW9sGf8NXvak/1U8IC6wPDUlxzCT91tXQthzdAEyyMBXT8JLduZXqmIq6CRgJdIvc mPsvIkuvFt5N3ZWhscjGFxyav2YcoPfd1XbXjmLpbNqDz4+OyduFuKQ6dA0hKOoiwSyq x+ej5+FdfSeLupTDqKZ4LLElNRZBXzrIHaKVLFGXAuBHbCc7QR4vgeAF2J40OzrA0xJ2 K2YYsmOeab2Fb//WHvTKJY/gSI+crcn3dYefdd7+WoVyeu7gURe2kknwTsma+A86Rieq 4bCRBhxWgjK5Is3f1lx8fxLtBq+q0Hc7KDmyRrZ1Bn+USiAhMYqPwaMRCE7JCEFe8u/6 gtHg== X-Gm-Message-State: AOJu0YwXTJWhT8szrJMvxjdlk6+zrGlR7O2+coL0DN3c5frrQvKB6NFL HFnd9UnSBe5Zjk0up+/Q7gOZxu+VwM3ST5qJrfWeJfOmx2NFs1QjXYWH0NrXBZQvIoLdciY8UUc LrYweOHEoAkEbAC6LALNeiMNEcEc= X-Google-Smtp-Source: AGHT+IHGH5+wxFiJIzJz1GrRtKkM3SP8B4KSnxxzJK/OaI7rpcGD7sM8Dok0V6Ggq/eViFkfCqTQmB8kjNnrj++v+Aw= X-Received: by 2002:a5d:6e55:0:b0:33b:3c79:9182 with SMTP id j21-20020a5d6e55000000b0033b3c799182mr5473051wrz.3.1707762097193; Mon, 12 Feb 2024 10:21:37 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-6-alexei.starovoitov@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Mon, 12 Feb 2024 10:21:26 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 05/20] bpf: Introduce bpf_arena. To: Kumar Kartikeya Dwivedi Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Eddy Z , Tejun Heo , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BA92240022 X-Stat-Signature: pk6k4h3egt4im4wb79e7xz5pw1kbu17a X-Rspam-User: X-HE-Tag: 1707762098-175022 X-HE-Meta: U2FsdGVkX1+M5PgF/oUHc5hFz9aEclDJQylEmcWE8ApEJYvv7Up27CVjXvrEA/0HM/Pju10fjL9mgB2CL/tfRLNs/BdkPYs80oEA2xr5PE6os/mYzm6fhSDc9PzVjHT1GYZ2sZfMmgVAsZku0TdrcTOidvmnh1jDMPDfTx3o63fl2L5Q6SpktEJbcrU/L+k7WkNP7aw0fesf6f4sE/YAb4Rieqczm2s7XSc5LGVwOtbLEtfK6fW5W5wqIn6HhNZDQhRwcVes3Dc1hxq6EdOqK9xG+TT3yoUMcZ6elOFafj04vrq5TlOzkFD7T/A/3Yk0udd/gj1Yaj5/PmkFJ9qCzXCoyS+e6I5nLOU/dLERGcALe07aLGaUJ8ERi/5V5urUGJhf6Lgo7rVMEkmbm8YD8ECkFIOpDpnRNfhCk9CuLwmEDMLUKgxK+zIOBTl3IuPiroc62Ccw0m7dvJhaepLuOGltgm9m4/vp6Y6jQWqrJidSIVgyVaOGKsEOmGu/rHksEhkvcHmHFoVCh0Od6tpdDQ5G/SMxXx3iX/IiA/0cJGw69uW5AfQSSw8j9r3TXe/SpKRuqyuV22HvYR0Yf3DzhFXG0AHvf2OEh3y80Z0u3KNG1P8gzgNDPRiX5JQUKvKBTqFVvlI+IXpzD8PiIsAPzd6FLQ18WhwCc3EFWrYmU3Gc/ivkNdlEIdlUxNIU66GvxV+DHfnrvasVarjaGcZkYPQ6LEJTDnjQmCUdyAwg4uEA0ed/VUWbb4odWTsJfCpDc+IBKh658D3V3fYyoW79DWHZytDflVJmng9O6OpSttb8SX+DNYtfr1QvkjhfAgTnLe+8Aw5XvzSDny1TKu7+rUWoH3OVa9dQsLu/C4eYfQvqYA9VLwCEFtiGOGt84GtDuAhWAhmBORu58+ZajhABaP0KBxTCnUQlG9azKfctaL5zMYFgwSf3iXQn9akDmiz1ntAR+b8yDV2kVolKwLt YFWeGJaN o/eWZdDaX6RWhRjdV2ELktMG9skcyRg7jgFoPW6Ne9eHwW6ZhO/DNe4ec/ySmZIKhpSdPZd9qt+jSbWMFl36vWzbppHEPsXdINKgLlOC/LbQdJcNMSuwy3ZtzslChBEkcLp/yaUl3rYXtjpzEgB5RAZLdDUgMizDuHkW4pdk5RAX/QsHbFQmPSSilswuARihVa7/4nlBVQfdUVM93PKikOOm8lwSIdVCYx3hC2aWWCM4z3eWzhm6kzMr06zoDO42Ew/FjjkYQFxu5earA5ig/sxDO3rZ1uyB3nqYCm8o4jSFD8mh/WO7Bt/jEnz4bYsmUjSUHpdy65uitviqqR2p0WolLsoiWV5cnVCqbbC7iU4hTgHr4ysCFfbLUy2b4G150OcNrPcxhEIcgvGuYIfuMkjYhIYP8b1XNIGIK5d/dOzd3KoPqZibWKp1aY7U+tA4n3L70kYeTO+cA8Sw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, 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 Fri, Feb 9, 2024 at 11:41=E2=80=AFPM Kumar Kartikeya Dwivedi wrote: > > A few questions on the patch. > > 1. Is the expectation that user space would use syscall progs to > manipulate mappings in the arena? any sleepable prog can alloc/free. all other progs can access arena. > 2. I may have missed it, but which memcg are the allocations being > accounted against? Will it be the process that created the map? > When trying to explore bpf_map_alloc_pages, I could not figure out if > the obj_cgroup was being looked up anywhere. > I think it would be nice if it were accounted for against the caller > of bpf_map_alloc_pages, since potentially the arena map can be shared > across multiple processes. > Tying it to bpf_map on bpf_map_alloc may be too coarse for arena maps. yeah. will switch to memcg accounting the way it's done for all other maps. It will be similar to bpf_map_kmalloc_node. I don't think we should deviate from the standard. bpf_map_save_memcg() is already done for bpf_arena. I simply forgot to wrap alloc pages with set_active_memcg. > 3. A bit tangential, but what would be the path to having huge page > mappings look like (mostly from an interface standpoint)? I gather we > could use the flags argument on the kernel side, and if 1 is true > above, it would mean userspace would do it from inside a syscall > program and then trigger a page fault? Because experience with use > case 1 in the commit log suggests it is desirable to have such memory > be backed by huge pages to reduce TLB misses. Right. It will be a new flag.