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 1F0FEC7EE29 for ; Fri, 19 May 2023 16:14:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC1CB900006; Fri, 19 May 2023 12:14:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4B1E900003; Fri, 19 May 2023 12:14:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C5AA900006; Fri, 19 May 2023 12:14:33 -0400 (EDT) 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 7D900900003 for ; Fri, 19 May 2023 12:14:33 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E58F580A3F for ; Fri, 19 May 2023 16:14:32 +0000 (UTC) X-FDA: 80807502384.30.4919E5D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 36CA414000A for ; Fri, 19 May 2023 16:14:30 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eufy765D; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@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=1684512871; 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=Fz+wK2bZP1sraT2XiN6NtrwE/rOfNyDpEE6MkPOkdOg=; b=uFlXcee1pNymuTaKURI50J4UfiNWSQu4MV+Df3A7sSMDGk/X+dwDbTm/mG3HXrXhlY6LLB KZEYUXSmMimwxmocsacYYQdyyT7adJBFvhZeDFJO00DnY0J2WuOL6xumTBoUNF3ubX5UgZ bsexxQZJbw3Xxf+4ou14ge/RBJc+TP0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684512871; a=rsa-sha256; cv=none; b=eoVvx8EBvSZIxlfTtJCpBq5W9MptautwMp8PAqj/jGsT8xXI5+tb8BFEdshidw4s5HHuLo 2rM6BrsksYh/l/7sfA9RVnamqoNV//bBwa3xi5C2QSMekZe1kk1yOmDcF0OY1Epkm5FXhx PqyclYcUMqr6mX8ee9vGchAVjkMUQUU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eufy765D; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org 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 dfw.source.kernel.org (Postfix) with ESMTPS id E43CC61473; Fri, 19 May 2023 16:14:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 971B8C433EF; Fri, 19 May 2023 16:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684512869; bh=cj9XLln61NnV+iOtJGxKSspk1kIfcgYZKJDT3am1C1c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eufy765D0jvm/ghu+mPlpSqSY5QRnhPl/E1ytFy0IkOma2vMgd21YFe5ivcmxAF6i bXQrLIDGSPVIn3PwHk4jhjfSx/433XuH5DO7GTA9qFKiKmYQx9zOAZ59EEBt6qIq27 fLTm7kZXVp3+60dzEEtsvuds4JY3GqfgCBg8fThbiQ2+d0KpFqwbegxPp2cSER8uvm AEEO88GrS5L9tEOwoFa7u2O7Ajj4Fuz96itWjYsiqXboee4CZsbi6dmSqzbN3wAzVN JpwXnC9LW/FvtyhAylJVBdT+fciGQ0Lz63JxKigbeuIKr5y9jBKsywHtrVeBw0cEjm BrjRBD2jWgFQQ== Date: Fri, 19 May 2023 19:14:14 +0300 From: Mike Rapoport To: Kent Overstreet Cc: Song Liu , linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() Message-ID: <20230519161414.GF4967@kernel.org> References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> <20230518152354.GD4967@kernel.org> <20230519082945.GE4967@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 36CA414000A X-Rspam-User: X-Stat-Signature: preu4d1855r9w9t1jrd3qsfcyhririuo X-Rspamd-Server: rspam03 X-HE-Tag: 1684512870-618805 X-HE-Meta: U2FsdGVkX18xpF6ywL6yiWSAjtifWDJSg3kyyQUvadLMu5NmWztaWCSl3sa7jM2j7ADOZ9Y3W8jnMXAfZWK7T6vFmBTOmBr2u1gpI4/Ub9jMlnfXEahtXIDLVsiyWfsSoGvLGyA/7bmF//HmfhMfaPbTxH4iLTErfRYXjo/Uu3Emxlqe1K0z3Vuot2qckZOeOPPLepjq53Xf8GJdL2HxhnC8zlHSW9MVVFAQrJN9H8UvjgxREQkF87ghUraJKwQo/6uILKqyk3RDU7iWGH1W2UP8Yhk/UEJVT1bEGbbY/JOvXLwNrbcmTRJS3N0+wD2jxrPigrHG3wp+48KfQ2Dpz9UtIUG1LQn9+C29dz805WaXAuiJUGU9MyjbCCz5WBDsBcG36txBgZrr4f46TXWJCmqa4PlNaC3zrgRblHzlwVzSAsHHkxXmv1M3Ghbu8LFg0AacuYesaX/IoeOC2bs+qyL6PZdmw/NxT1IMJ87vBiSwhPGsXi0UDp9Nxd/U8eQBA75ZwVeYSL2Kdis3GSlRJJkDLTvVlIkXE2vwDT7kl2DbkKjrKeXp9dXaeihAcfl4maYy7rqtt93nxJLtxvhrhefz3unB/R+eGFnsnHMabswj5hKP6VGYr5dTs7ElnBC04/pHnz1WumBiiTbVtviRTnRx5q7N9bbiXYYOwK/wk1HNyxnwcu9ttfpHpf2zwDLbndDBtVY8pN31tIIRx1ibgpvV4K8pEMUPGbnvqn7+EB9woaPRUENMDaQiL9cFky3urUu/5eQGh9LD18VKb/FMr++gGViXzXH1A3+hBCaJH3z6SSNfFDzhxYHKnKPq3QgVqv0m5NraJydK6KR2c9zmIaQ1KDIyBXzXrz9rzgxX+UvcLsxNz/2L+rgGFIuS0EyxaLAsxNa/2aHh0HE7zeH+k3Zv5bVLt+UbF5iuJEpJNfqgMdOCW9Y0xAHCyXlpqMEg39XGvligldNk7AlZIBn rVC+MbCk 34NAQBpZvI+dMMYBfinTxxXVVTjUmuE8Vz72AgAnNXQvbWBOPzwxKv+YaP4EcGp12GXknOo/AOVVm+ruPGMjKfyBBmBtkKLe+nxXbXzyjB251AUiwE1ODdQCkwcI3h2hzMSIWY60w831rk9gORPQnujsjuQ3TetvynErfWWSbF5mytjz2x1KgcP6t33+o3ohIrpSw+47uer/evv1NtWdF7pr0eKoGbQFrSO+XE5Hl9vlJOP0QUL4+MachDQaKmGo5/q22uxkhKOq4JqkKWVtc07GaZsSyMAnyCyUU6XyDoxZjnT2vEv+Xoc/bcGghFgtpZq/w4NKzVMdoNo2gLMMavyuj5w== 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 Fri, May 19, 2023 at 11:47:42AM -0400, Kent Overstreet wrote: > On Fri, May 19, 2023 at 11:29:45AM +0300, Mike Rapoport wrote: > > Your allocator implicitly relies on vmalloc because of module_alloc ;-) > > > > What I was thinking is that we can replace module_alloc() calls in your > > allocator with something based on my unmapped_alloc(). If we make the part > > that refills the cache also take care of creating the mapping in the > > module address space, that should cover everything. > > Yeah, that's exactly what I was thinking :) > > Liam was also just mentioning on IRC vmalloc lock contention came up > again at LSF, and that's historically always been an isuse - going with > your patchset for the backend nicely avoids that. Unfortunately not because we still need to map the pages in the modules area which is essentially a subset of vmalloc address space. > If I have time (hah! big if :) I'll see if I can cook up a patchset that > combines our two approaches over the weekend. Now there is also an interest about unmapped allocations from KVM folks, so I might continue pursuing unmapped allocator, probably just without a new GFP flag and hooks into page allocator. -- Sincerely yours, Mike.