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 7447AC43217 for ; Mon, 7 Nov 2022 18:35:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBAF36B0071; Mon, 7 Nov 2022 13:35:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C44226B0072; Mon, 7 Nov 2022 13:35:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE5716B0073; Mon, 7 Nov 2022 13:35:33 -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 A06D96B0071 for ; Mon, 7 Nov 2022 13:35:33 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6FBBE140F85 for ; Mon, 7 Nov 2022 18:35:33 +0000 (UTC) X-FDA: 80107499346.27.62107EF Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf12.hostedemail.com (Postfix) with ESMTP id BDBBA40004 for ; Mon, 7 Nov 2022 18:35:32 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2F175B81613 for ; Mon, 7 Nov 2022 18:35:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DF2DC43470 for ; Mon, 7 Nov 2022 18:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667846129; bh=fENHnhkhqiC80pvSoAM8W6kCQuZClzcUZr2IPdz27dk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EsFHbIeiixDS8zVIarcY8ICr1jNd9Ksm/304Tp8gtClKvC8uw/vslp2W+dEvBvpTU W2//bi8Anr53suBdnD6cYpLIljztqMLPXVrxXfa5MwEn0ZdiAZnwK3zTnWhbq6HRUu r4uhkg668tKk6vIuuQYEUCrpU4I30oTRxdPyqeZYWzoh6Jtu5YP51548GndGediyhJ cFQ+FdgPd1SHNV/6NLgiGnQSMzxsyycVAZDTLDhoMpA5oo++z07tNGulSrsUfga5oK qJfTnT54xNx3s7uf5awDYMqW44ChdUExub9HIiVoomHNfWqWt5MaURuwVGi3urKcV4 QLg9JLgzsm9dg== Received: by mail-ej1-f49.google.com with SMTP id sc25so32448482ejc.12 for ; Mon, 07 Nov 2022 10:35:29 -0800 (PST) X-Gm-Message-State: ACrzQf2PkCevOkzcHJKfOIOzZFiJ9XvrxuT0XR4i0B/8zEy2l1gBtagN yeEObLHe2+GuMRYiq2zJXbWJ53PDYPqpmX9CjSc= X-Google-Smtp-Source: AMsMyM44YTREuh/FSMIUcNOOl8bwLtjn2YpJLhrQ1cQjx8k5h60aCb5U74U1hxTGHGX57uh/mBkLWuQ6+301UkyYs9I= X-Received: by 2002:a17:907:b602:b0:7ad:e82c:3355 with SMTP id vl2-20020a170907b60200b007ade82c3355mr36112192ejc.3.1667846127423; Mon, 07 Nov 2022 10:35:27 -0800 (PST) MIME-Version: 1.0 References: <20221031222541.1773452-1-song@kernel.org> <20221031222541.1773452-2-song@kernel.org> In-Reply-To: From: Song Liu Date: Mon, 7 Nov 2022 10:35:15 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v1 RESEND 1/5] vmalloc: introduce vmalloc_exec, vfree_exec, and vcopy_exec To: Luis Chamberlain Cc: Aaron Lu , bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, peterz@infradead.org, hch@lst.de, rick.p.edgecombe@intel.com, dave.hansen@intel.com, rppt@kernel.org, zhengjun.xing@linux.intel.com, kbusch@kernel.org, p.raghav@samsung.com, dave@stgolabs.net, vbabka@suse.cz, mgorman@suse.de, willy@infradead.org, torvalds@linux-foundation.org, Hyeonggon Yoo <42.hyeyoo@gmail.com> Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667846132; a=rsa-sha256; cv=none; b=guesd0agL3LXeWsZ4GEUkuTsQnkwfAxkns3t3tzi7ZmLCqdne1umHMfL+ZnG0LVQwKJSE2 gx5p+JjVC2Wd7VdSscrGDrDmuNkrulBTfneIcxX5ZAncYH0tgCQgS/1s8KeItTAYoxotC+ v1cOueopSuDEdixXi60jjPFDT5eL5JA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EsFHbIei; spf=pass (imf12.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667846132; 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=vmRgf5TrFm29OCCe91hDmLsiQhU7XI8iQxajDcUHQDg=; b=sVuCZ4JgkNVXEINNPpaUVcjQsd6deUAyRxOhcbQVDEKf4M0C8NQsDgDV7XZ4Elnlsx3fBV efSuJgxHT9EzJmtNbP74TFQupbdAt6VAoA4okaKFVRrm9LaKvhUg3h36Xy+K9y1VEmpep5 nq4b5pzA3z4iNv7sFInbNlN0t0/YSKo= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EsFHbIei; spf=pass (imf12.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BDBBA40004 X-Stat-Signature: e6soek3e9qozg5jhq8sb18fsfpmg47xu X-HE-Tag: 1667846132-307391 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: On Mon, Nov 7, 2022 at 9:39 AM Luis Chamberlain wrote: > > > > Some imperfect things I can think of are(not related to this patchset): > > 1 Once a split happened, it remains happened. This may not be a big deal > > now with bpf_prog_pack and this patchset because the need to allocate a > > new order-9 page and thus cause a potential split should happen much much > > less; > > Not sure I follow, are you suggesting a order-9 (512 bytes) allocation would > trigger a split of the reserved say 2 MiB huge page? I think by order-9 allocation, Aaron meant 2MiB huge pages. The issue is that direct map split is one-way operation. If we set_memory_x() on one 4kB page out of a 1GB direct map, we will split it into 511x 2MiB pages and 512x 4kB pages. There is currently no way to regroup the 1GB page after set_memory_nx() on the page. Thanks, Song > > > 2 When a new order-9 page has to be allocated, there is no way to tell > > the allocator to allocate this order-9 page from an already splitted PUD > > range to avoid another PUD mapping split; > > 3 As Mike and others have mentioned, there are other users that can also > > cause direct map split. > > Hence the effort to generalize. > > Luis