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 AF824C47088 for ; Fri, 2 Dec 2022 09:22:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B1C26B0071; Fri, 2 Dec 2022 04:22:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 461396B0074; Fri, 2 Dec 2022 04:22:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 302356B0075; Fri, 2 Dec 2022 04:22:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 207BD6B0071 for ; Fri, 2 Dec 2022 04:22:08 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CDA6B1C5B0B for ; Fri, 2 Dec 2022 09:22:07 +0000 (UTC) X-FDA: 80196824694.26.CA8FBFA Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 3E58C1A000B for ; Fri, 2 Dec 2022 09:22:06 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=tNwNfn2B; dkim=pass header.d=linutronix.de header.s=2020e header.b=mJcGxkko; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf19.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669972927; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jN/FnY85dfL2uWBcKIUq9YWjB9CWbQK73JR0ADLNweY=; b=ByEQ0f8OAQwUfYkQHWOqWXEWrVF6CPUUs+cXxUVj8YZwS41lKm+FZOCJYnHEYXhFrYqr7i edzcvJMEDrFywFdvxZE8R0vi72K2fRLAr1y8/zy/Lu204HYIOzcb2DXiN8LAgRmnjjHEfB Lq7BLOvSYEPV412thOOLVfAZ3QVvSB0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=tNwNfn2B; dkim=pass header.d=linutronix.de header.s=2020e header.b=mJcGxkko; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf19.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669972927; a=rsa-sha256; cv=none; b=0E6NN5YmXY4jnnu1U9XOoESDIaJEf84GxLp7BF33NMKKFlG5Zo6ogyrcLrMfesDZOpvp/U ZxTJYTi/PmYb9y4fbpiBuUieGqr9mAXaDUlEID6rdezE7dp8zYAi8b7lchnHxezqdICGyU Utdu/fj3tZ6o6s3fITdOlA5NMjeNjvY= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669972924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jN/FnY85dfL2uWBcKIUq9YWjB9CWbQK73JR0ADLNweY=; b=tNwNfn2BoTpguFlNmMcCGmQZ57f7O5ptYfE84121JapxyM2IJS6BE1wxmO2v5OD+4hIId3 j30CY9V70/llWqEDMevzxkyi3b/xUrUGErjYEpt4SosVrzw5D17UDthk5VGf/Ah5klEsTR BDjNlTy7+AtXsodKffEhS2UaniGsh8N8VEb9Lv8EaRrw8ioXllujlA/xs9slSAvChPrD2U xGlq4QE0E0zLwxHnmX5Jt7xJCEREBFIwkanT/MfjSMGCF4t1L3xGcOiorD4PFZuItCkvjF NO4cqd38O9swBp+D0Hiq5q5ccKgc+v7Fn5jOQUAV51+vkS1+LOiB4nkTq7vNNA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669972924; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jN/FnY85dfL2uWBcKIUq9YWjB9CWbQK73JR0ADLNweY=; b=mJcGxkkoiGFDkLQsDp4UFhcfjGwFIXBUDGVyb1LS6iaseGGipALH6oQ6ZGIsm5oaxAeixh RHi5kyqdadQ6p2Cw== To: Song Liu Cc: bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org, x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org, mcgrof@kernel.org Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs In-Reply-To: References: <87v8mvsd8d.ffs@tglx> <87k03ar3e3.ffs@tglx> Date: Fri, 02 Dec 2022 10:22:04 +0100 Message-ID: <878rjqqhxf.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [0.49 / 9.00]; SUBJECT_HAS_UNDERSCORES(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[linutronix.de,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[linutronix.de:s=2020,linutronix.de:s=2020e]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; BAYES_HAM(-0.01)[46.83%]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_SEVEN(0.00)[11]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[linutronix.de:+]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; ARC_NA(0.00)[] X-Stat-Signature: hwjmr9n3w3gsfs8fpgjhfqtcjecnuqro X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3E58C1A000B X-Rspam-User: X-HE-Tag: 1669972926-964926 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: Song! On Fri, Dec 02 2022 at 00:38, Song Liu wrote: > Thanks for all these suggestions! Welcome. > On Thu, Dec 1, 2022 at 5:38 PM Thomas Gleixner wrote: >> You have to be aware, that the rodata space needs to be page granular >> while text and data can really aggregate below the page alignment, but >> again might have different alignment requirements. > > I don't quite follow why rodata space needs to be page granular. If text can > go below page granular, rodata should also do that, no? Of course it can, except for the case of ro_after_init_data, because that needs to be RW during module_init() and is then switched to RO when module_init() returns success. So for that you need page granular maps per module, right? Sure you can have a separate space for rodata and ro_after_init_data, but as I said to Mike: "The point is, that rodata and ro_after_init_data is a pretty small portion of modules as far as my limited analysis of a distro build shows. The bulk is in text and data. So if we preserve 2M pages for text and for RW data and bite the bullet to split one 2M page for ro[_after_init_]data, we get the maximum benefit for the least complexity." So under the assumption that rodata is small, it's questionable whether the split of rodata and ro_after_init_data makes a lot of difference. It might, but that needs to be investigated. That's not a fundamental conceptual problem because adding a 4th type to the concept we outlined so far is straight forward, right? > I guess I will do my homework, and come back with as much information > as possible for #1 + #2 + #3. Then, we can discuss whether it makes > sense at all. Correct. Please have a close look at the 11 architecture specific module_alloc() variants so you can see what kind of tweaks and magic they need, which lets you better specify the needs for the initialization parameter set required. > Does this sound like the right approach? Very much so. Thanks, tglx