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 EDCF4C77B7A for ; Fri, 19 May 2023 15:42:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55037900005; Fri, 19 May 2023 11:42:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FFEA900003; Fri, 19 May 2023 11:42:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C7C0900005; Fri, 19 May 2023 11:42:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2FC2C900003 for ; Fri, 19 May 2023 11:42:58 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F3E6640ACB for ; Fri, 19 May 2023 15:42:57 +0000 (UTC) X-FDA: 80807422794.29.789653E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id EAE7B4000A for ; Fri, 19 May 2023 15:42:54 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=W03aV4Mi; spf=pass (imf04.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 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=1684510975; 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=42lD46/C0m++0gtSXHeH7vh3I6VJML9hciiQaap5vLI=; b=a5nvmCHnPfoWrDu2hOZZwCsjWUnGSSH4Hxxl906AUSCuxKYVlFyYNxkegIRpMzUyy8X0ZY /W6PAGwmGaA6I7v8TSFFx9Cx7C3RWncy8d8x/HoUCcI3ZTCo4A1fhvuRFg4Zgg7vuX0fTT 8YzL6JbP3Z/yCahfFx4eeEUP+CKxaqA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=W03aV4Mi; spf=pass (imf04.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684510975; a=rsa-sha256; cv=none; b=c9bvn/BkfTj8KJj0nyskondTxIT/G7LfaK5VQK9mCniNhks4owRfeFhiCN5MTqF/mEx0sd Qvu1B1xhwjQZ7mr7dxEB68tBlAuYO+VZfYJdhfy2qIdbu8CigYOpLFdckNiJA+nrtUonw+ rPi3fgJe1nbvyv/oKMsTdX1t0SuntOo= 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 8B3D8658AF for ; Fri, 19 May 2023 15:42:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73246C433A1 for ; Fri, 19 May 2023 15:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684510972; bh=r6KNElAB9lNue2/Hd21GsrXEksf7jxTS8vfcJaqZy9Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=W03aV4MidBBBiz6wuT/nE4J+uow5ECmz1loXa+08lTMgAi8VpQuaundC0ZjFK7WpS evwV/GDr0WeKUboUIcNB1G/AV6oIwDwZ/0C9PhcNpyLW0rUjznNI0QvOnkEJ1iHEMP 8LNiAre/2wCMaicM8BkYD6r3MP3ffiWxwMPgUTxKeVPr4QaSvdrtRsJPin3u9TH5fJ vfPSXjZBn9408HM8vcU+9pydD5kc4ehDgLSa1GpHd8oqqMG44afoJE+LnFZ1+uO65N X3lZcjCTLHlmLM1turvJnnX85uTGJTDM1oRbLHQ7nbg86eXdhT2mBXqo6yrfaZmp2Y mqGCUuhzt2gGw== Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-4f14468ef54so3918251e87.0 for ; Fri, 19 May 2023 08:42:52 -0700 (PDT) X-Gm-Message-State: AC+VfDwISNonGWfX8lIBr/vtI+fHijUo9TwbwuM7sWtW5gFQGu5/Ajja O1Hc66WFi+hw0wBG6HdkNxVWBTMFHeXaZzxCm5Y= X-Google-Smtp-Source: ACHHUZ6jji5zztX+v78YYGws8fwDsVNnwkuvXzZcAzdclQJq6KKtQw6rbL+vMslnBDlqaubv73+qKbm170OWWKTXl2A= X-Received: by 2002:a05:6512:908:b0:4f3:9136:9cd0 with SMTP id e8-20020a056512090800b004f391369cd0mr756798lft.44.1684510970433; Fri, 19 May 2023 08:42:50 -0700 (PDT) MIME-Version: 1.0 References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> <20230518152354.GD4967@kernel.org> <20230519082945.GE4967@kernel.org> In-Reply-To: <20230519082945.GE4967@kernel.org> From: Song Liu Date: Fri, 19 May 2023 08:42:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() To: Mike Rapoport Cc: Kent Overstreet , linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EAE7B4000A X-Rspam-User: X-Stat-Signature: hafw6tb4eksa3whw1jndofurwgha81zt X-Rspamd-Server: rspam01 X-HE-Tag: 1684510974-876624 X-HE-Meta: U2FsdGVkX1+VYGMSmc2XdHYvUWJBl9DCwOv2Wsxcvz6NB8gLe0Zqc95w6QL11OZTb2khWlNh46Q443rQLmzJCeU79zhU4IuSQnFj3UYji64O1AeXCGgFMVnVyUTofFW9nhMG5/oLiK+n/qGUDxL7D1/rGrqOqeOJKXyv640CGJH1IXgkEayTJyiiT+9dTV/WsrImazLxahObcgp8KMZaRj5jdR/AE6omWBZWjXlr4xTWNvOsZH+T9aDq5/N94/BPKpfUt1LeqdI8Uf0r76rXc5bJ7JtOoxRQsdKI/N76CvtljQDmXodtNMXZXlqUp/04QCUVGt3q5JbFjOUlNkX+HUMl90NZdq3hHuXduqwW7W5abiszrIVwULOVBBYtdML5SwFZbxbPru4bUTvB9WItMoIwBNbjvHm7z4vN5JXV9w5Pf3bK+K99JGsJdZuHktUUpQEjqi1sIXWQdCzXpVvIX+8HOET6D7mbc7NKWJc02NaIOCIZnnE07xsSGAyZ+MmafRiXic4XJdV27fhCXYCuGQ788ULLCxMm5RyFTSdFHBuNSD+1KcZObSvCXfxK/Aa/6eFSdoRpa3o6W1h/wRARfObeV9NBV4I/sYte/kiHpyAv3mF9z70oTkDSmSRmDevxNKNbPUsm6M6bRWaQMsBZstuHcKcbcBvtBHwbXQFZxEPvNUxwEMzJJgUHiOHrmxQJrLjmw++fLhnm9JpPLRLE41RNP3btveaJDPNBi/6zfdTCS4NfL73lEITZCZ8Koh2a9KiRGD/pi25i0VPirhdgb3SnVOmgOOVBHdBTvl+zEOhfqU2ewJnP3IfoQh4kKtbrPyaB3SJvFJ3kfphDYwvv7CJ9gCyNpK5MR7exgYcGK2PMPYzly95mA76G/q2jRHoufEMn2zwYfoM07gEH0Jddj30WrjsCntNHu92jixvopp32pIejEFfYdWcH7RPhFW0vZpWO4TJw8zTjIjVsqPK Is3vKJwq VrmWCyDxJwy+gFE/y3WbCZmRtr8uqewuxV45kBcpJ1UtGFRLyyMvDk93JHFpAOGQmtqycyHMnPqOWJa3774XjqztvfbP6u0BxJcjU4zyuDbsa/Qlgy2Pl8Lvb+ySKo3EMMwGUeyZGz1f0zM5C0Gahdr1hg2JLGeArJoYTdQ3QhdQHqu3qXXhAfFS65z3XBpALO0/DKT6Bk+KtqO78AV5mH6Vyf9E/slzpZqiJ+isR5CCJXC4tJR606sjYmdM/q+5GMKwyUjqZgQnj0hD6Xn3pIslSBDmBZzSBHbnNlQhmz868gGtGNvmbystNemha4qd1kStx8YOb/Pcmd5Mc5YIctXG13iz9JT127rTd6mNoIkUyWKA+naoZ9nKzJ58dBsQB7w06ImK+V0McpBcPZHzPVYXwf/Zhg/4WzJAWZe25zVNKrw4= 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 1:30=E2=80=AFAM Mike Rapoport wro= te: > > Hi Kent, > > On Thu, May 18, 2023 at 01:23:56PM -0400, Kent Overstreet wrote: > > On Thu, May 18, 2023 at 10:00:39AM -0700, Song Liu wrote: > > > On Thu, May 18, 2023 at 9:48=E2=80=AFAM Kent Overstreet > > > wrote: > > > > > > > > On Thu, May 18, 2023 at 09:33:20AM -0700, Song Liu wrote: > > > > > I am working on patches based on the discussion in [1]. I am plan= ning to > > > > > send v1 for review in a week or so. > > > > > > > > Hey Song, I was reviewing that thread too, > > > > > > > > Are you taking a different approach based on Thomas's feedback? I t= hink > > > > he had some fair points in that thread. > > > > > > Yes, the API is based on Thomas's suggestion, like 90% from the discu= ssions. > > > > > > > > > > > My own feeling is that the buddy allocator is our tool for allocati= ng > > > > larger variable sized physically contiguous allocations, so I'd lik= e to > > > > see something based on that - I think we could do a hybrid buddy/sl= ab > > > > allocator approach, like we have for regular memory allocations. > > > > > > I am planning to implement the allocator based on this (reuse > > > vmap_area logic): > > > > Ah, you're still doing vmap_area approach. > > > > Mike's approach looks like it'll be _much_ lighter weight and higher > > performance, to me. vmalloc is known to be slow compared to the buddy > > allocator, and with Mike's approach we're only modifying mappings once > > per 2 MB chunk. > > > > I don't see anything in your code for sub-page sized allocations too, s= o > > perhaps I should keep going with my slab allocator. > > 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 par= t > that refills the cache also take care of creating the mapping in the > module address space, that should cover everything. Here are what I found as I work more on the code: 1. It takes quite some work to create a clean interface and make sure all the users of module_alloc can use the new allocator on all archs. (archs with text poke need to work with ROX memory from the allocator; archs without text poke need to have a clean fall back mechanism, etc.). Most of this work is independent of the actual allocator, so we can do this part and plug in whatever allocator we want (buddy+slab or vmap-based or any other solutions). 2. vmap_area based solution will work. And it will be one solution for both < PAGE_SIZE and > PAGE_SIZE allocations. Given module_alloc is not in any hot path (AFAIK), I don't see any practical issues with this solution. It will be a little tricky to plac= e and name the code, as it uses vmalloc logic, but it is technically a module allocator. I will prioritize building the interface, and migrating users to it. If we do this part right, changing the underlying allocator should be straightforward. Thanks, Song