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 28844C4828D for ; Wed, 7 Feb 2024 13:33:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A85C6B0071; Wed, 7 Feb 2024 08:33:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9583B6B0072; Wed, 7 Feb 2024 08:33:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81F996B0074; Wed, 7 Feb 2024 08:33:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6D1386B0071 for ; Wed, 7 Feb 2024 08:33:48 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 14A3A140DC5 for ; Wed, 7 Feb 2024 13:33:48 +0000 (UTC) X-FDA: 81765100536.23.73C8B54 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by imf12.hostedemail.com (Postfix) with ESMTP id 22AF74001E for ; Wed, 7 Feb 2024 13:33:45 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QmfmA6E1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of brho@google.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=brho@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707312826; 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=ClRRsnreAQAmzChpNpHdXijt7xDlDPCVlkBWfOdqK0I=; b=drrILjlOCFpYtb7YmlVHFPVNVP6yY8Sqmwy12Tsj7aw6BmzjvR9IVBdtstXdxP5/7RElGf RMgDJsAfZvRVqT43NZHVvdj3+l5jElxFO6jdLAAxKOn8n/wyy96AEiwkRuaMeYssqdR+9S vxpD2RJXf9FWrfsAXO4Zd7z7PwsvWUI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QmfmA6E1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of brho@google.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=brho@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707312826; a=rsa-sha256; cv=none; b=X1jnDv7UcSXIpMZP7snZ6zNc8wgHRgO4SEw3syMeUt9+GFgIN0x2g7A7DzuABa6H8XG+01 wjdNlqelZ8ktCEUgGhH5aOf5xjRUdPNH5LJQxCbYQsT/9KqQmyPUJqc44v2ssoqCaaf4QL I2t2e+XL2HF55SzQn1IEu0M4uTFd+nw= Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6860ff3951aso2933206d6.1 for ; Wed, 07 Feb 2024 05:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707312825; x=1707917625; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ClRRsnreAQAmzChpNpHdXijt7xDlDPCVlkBWfOdqK0I=; b=QmfmA6E1APTIaa3fF0Uvdb4tL9K5HJ0O9aq7S6DIiiMNBlAlyt4cjfaP3nW2FlKOH5 vuRoVioHm9yU/PyBks3c5qu7PcCF0JaPFEGMsHIrPrjGYqQRMST55qucwlNRUME1ut9x f+VPkIhesJiJHgTB1i/j5TKYZFxLb8V4xhLUwrejTgo4lSyepyKbNBAgCxxK0lvJZwy6 2yFY+jGXOFdvY6noJu4DFixqdRDLhbmoGJLpcpAVrd9lOjvz3A5ytbcSZxofQuDPyzi0 OPzkhfY4A6K1TYwF7PYWD9dq5eTzyjVtHbPqY9ud2JLphzCmMGaVZ7G48Df+HiPu0yBT 1bdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707312825; x=1707917625; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ClRRsnreAQAmzChpNpHdXijt7xDlDPCVlkBWfOdqK0I=; b=qMY8ffhjs+sTIIib33Jldcls+wvOn5Fm0q7YU5zrn9SgrP528hK24GwCpypV8ZXQcK XwLaEmJwFCX+m8ZympmnW0hbjZOceZRh/97vFjK261S6/TZEVidJG2gjosNpEtpnS02g 1QuniHHxx+Cky+ut4EmDFZEIdmLNWmNizZG1ms76mlgj5ISnprO9ANhSKjpxyV4RaDUF YThscZiQepwmEc4/miX/hC+KZSdBY8H4QUvkWOL4N18CjnpH1sXmwXZcSOynOvXvn8xz iB2ljgxAzBPH9cHuX4EChn4B1qGmvWwk6ImPuSOQSCNt5tX+fHM/hs9U3WK4cXUMeq9z PmRg== X-Gm-Message-State: AOJu0YwBmVHdZtgpk8embpfUXm7sWRlWw5qac14N5xcW6Fqnh3N1DF+i o6e7yhnN886rtocRd23BR47+8DcQMGU0AVA3L0MLE+hlSL2yby1snfUBs9OeGQ== X-Google-Smtp-Source: AGHT+IHJ7T7P3rBpiYTjhQA9ZNtPtXI1J+NtXhagq6AjOiXKASkvq34ZbTAX25oyUrpt0oysBza+iQ== X-Received: by 2002:a05:6214:258b:b0:681:78cf:3920 with SMTP id fq11-20020a056214258b00b0068178cf3920mr6986214qvb.25.1707312825202; Wed, 07 Feb 2024 05:33:45 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWSYueSA73EqIF32rQqgxprdXVog3n1g97wgK5m5zoIB5W+diFaRHScbGNVnc9JQ6GEiAp4SGbASX4tQChZecj6TILmR+PAIbuKWKJOs46s5L8vfa9l3y+Vstr1LHjrIpEj0Y6Tw0SYfaZZilo5ifj9QGp1r6/hsaAIdOxODmPFEqGHITHXhKgfz8K8LD/9w+OKwhEUYz14VHjgwHCgG+6Snvy0DbYXx0A3Y0itW2SOiRWL0wwyypGxvpTmERQwY8NIxug+jj0rffkUL0bBHD6/Glrz6MJEE118zc8DAnoTfhpvg6w0VZMup4sCQj3rtEroIX8= Received: from [192.168.1.8] (c-73-238-17-243.hsd1.ma.comcast.net. [73.238.17.243]) by smtp.gmail.com with ESMTPSA id lx13-20020a0562145f0d00b0068c39b7a7cfsm587302qvb.12.2024.02.07.05.33.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Feb 2024 05:33:44 -0800 (PST) Message-ID: Date: Wed, 7 Feb 2024 08:33:39 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next 00/16] bpf: Introduce BPF arena. Content-Language: en-US To: Donald Hunter Cc: Alexei Starovoitov , bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@kernel.org, memxor@gmail.com, eddyz87@gmail.com, tj@kernel.org, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@fb.com References: <20240206220441.38311-1-alexei.starovoitov@gmail.com> From: Barret Rhoden In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 22AF74001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6yz9rce7f64eh9ni4a4db9rm6ewtzqc5 X-HE-Tag: 1707312825-161192 X-HE-Meta: U2FsdGVkX19KfGk6ZvsiyBGS5McSI12LPrS/QgQGfPiGNNuVGDNSbwfGE6lJri7yX6Uruf59+GJ0tNx1OD4Osa6G8Lgu3PQm6P8tgrGBcjQvNetp+d2gNCelDgny32sUoNniajb8YrSpp8HiOu4SqObA2hTHTRFHqu2RHNhlYB7iZGvBztwVn1ZlggxW6QHNJkw30kdxnXP+XLcvRxJzPMEL6/1wsSOFXW2d7yGxDxFdaR3eoSMrlEmVj2iJ7LbqPBmqCjF7NkLTjbhLWvneTN8pwhPBOZEDgi0lf1A3uh86OaSIOE4IyxT4XkVvQTGLWMPyLh0S4FFgyYpGZ8OMZQQa8bCJOHsAUBJkdDBIx+FiJ2PbFYHfKzVC9obpg2tJ8L0BlS/1jx8YpW6Qj43B7PdfVi1lRgv6j/ZHFTvRvYbGShOosSBNX54qsa+4LnAfjBVyfgCilPG+L2Yjntq+IhnTWFoRUuE1jhDdVmcwKcusp6oSRB1PTySdnZxpGbJ2IwbGER/Tt6oqZXgvq9WgiTT+8q9QNCEJq/YN5kzjXjULYHDyCPTSR5JFTgyTpGqDVXjYB0/vH+9/obdo6JmwnML/ND/a2A931mqkiuULXTNar56sR64LEh7lS4e7b1QgAfBI5PwxeeOMyYiJ0aegZzmnZTzDE8LZwQOCENRbQcbmzKYTWX12KBSWwPhqcDd4UWjrx/h/kHJVQdnCFxqCpbbF7spfIWnG1h5ZC31XdHSz0x2dng6dQjWQyZ6LPv8iMeVgFZUYmMYieElcoeFrOvM50qUTglcKqDUJLktOHx51Dxtf8RzXdlt0A/6c1bA1fu+tX+tYja3jno4nJIGitK8SrWtJ620YWkoAR4g7otsRf74aE/9kQDyaRZCo3rWm6z7lzsMDT9bTCe0OdmLu5W2RVa/o2Z++oZd/pb9WwAq/+dLbOXQ5LE5Anc85qwZDWwjxdscabK1bWOv1Oxq XQ4aDLWa bU0nm2IOeTXN8roB9NM1wqDHYBUXNg683ZUPkiQdJpzwieoaBmDwHYr3YXqgRxzwZ6wLqly0F3p5ynSu0QtiIr9USVA8H5frRnV4+V0oKLE0CAdwyXcVGAS/l1Q3eLK03ZV73y1oe6TLEWBDyH26neSrKxnRPXRvuIpsM5Jz/rIn+5NKydYJNypFL5xL2fj4u0Fdztns8FSFHf/R7zb6BS7JH1AOlHz3oSUEho83BjMG+/MrbZjlRq4JFDU5qLhVggCuCzfvVURW2N69CYXrc2yY2oG9PFJ7Bio474iOiXTBBahwJGQvmeqy+y5rduDUdw+NXBf8eVPcWK933IW6fsovGGXejgStQfJL8h7vVICPGYFNzAy2IGI3MaI39vv0J71zbN/CYhFppwvBHJRN63yxbaPMehpBpMB2ml0byQHsVX8rRyhIeCtlTbKKmVTnOOu+w9qaVcwePgr7XTYsKzunXDJLyKJz1xx6K 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: List-Subscribe: List-Unsubscribe: On 2/7/24 07:34, Donald Hunter wrote: >> Use cases: >> 1. User space mmap-s bpf_arena and uses it as a traditional mmap-ed anonymous >> region, like memcached or any key/value storage. The bpf program implements an >> in-kernel accelerator. XDP prog can search for a key in bpf_arena and return a >> value without going to user space. >> 2. The bpf program builds arbitrary data structures in bpf_arena (hash tables, >> rb-trees, sparse arrays), while user space occasionally consumes it. >> 3. bpf_arena is a "heap" of memory from the bpf program's point of view. It is >> not shared with user space. >> >> Initially, the kernel vm_area and user vma are not populated. User space can >> fault in pages within the range. While servicing a page fault, bpf_arena logic >> will insert a new page into the kernel and user vmas. The bpf program can >> allocate pages from that region via bpf_arena_alloc_pages(). This kernel >> function will insert pages into the kernel vm_area. The subsequent fault-in >> from user space will populate that page into the user vma. The >> BPF_F_SEGV_ON_FAULT flag at arena creation time can be used to prevent fault-in >> from user space. In such a case, if a page is not allocated by the bpf program >> and not present in the kernel vm_area, the user process will segfault. This is >> useful for use cases 2 and 3 above. >> >> bpf_arena_alloc_pages() is similar to user space mmap(). It allocates pages >> either at a specific address within the arena or allocates a range with the >> maple tree. bpf_arena_free_pages() is analogous to munmap(), which frees pages >> and removes the range from the kernel vm_area and from user process vmas. >> >> bpf_arena can be used as a bpf program "heap" of up to 4GB. The memory is not >> shared with user space. This is use case 3. In such a case, the >> BPF_F_NO_USER_CONV flag is recommended. It will tell the verifier to treat the > > I can see_what_ this flag does but it's not clear what the consequences > of this flag are. Perhaps it would be better named BPF_F_NO_USER_ACCESS? i can see a use for NO_USER_CONV, but also still allowing user access. userspace could mmap the region, but only look at scalars within it. this is similar to what i do today with array maps in my BPF schedulers. that's a little different than Case 3. if i knew userspace wasn't going to follow pointers, NO_USER_CONV would both be a speedup and make it so i don't have to worry about mmapping to the same virtual address in every process that shares the arena map. though this latter feature isn't in the code. right now you have to have it mmapped at the same user_va in all address spaces. that's not a huge deal for me either way. barret