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 0E725C61DA3 for ; Fri, 24 Feb 2023 14:45:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E7E16B0072; Fri, 24 Feb 2023 09:45:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6973F6B0073; Fri, 24 Feb 2023 09:45:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55F796B0074; Fri, 24 Feb 2023 09:45:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 46FEA6B0072 for ; Fri, 24 Feb 2023 09:45:38 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0D4A916083C for ; Fri, 24 Feb 2023 14:45:38 +0000 (UTC) X-FDA: 80502459156.19.6E1C65F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf12.hostedemail.com (Postfix) with ESMTP id 54AA440009 for ; Fri, 24 Feb 2023 14:45:36 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KoQCMpcV; spf=pass (imf12.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 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=1677249936; 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=MCifwXXmNCpo30PdbpAQVUEk6nTb/HnXCQmmWLF3uZw=; b=QFlPwby54frGzyfcL1FlV1eRcyUSc8Rh/yZqqxLRy9JTqfkHo6RXCk88mVIH/xvkXJoR3E yClMPF3Cq8vwzaUlqAS/lu7c6f7P/d00fqxqhHp33+P12L56gSGzmVrE0ozHP+vMOamLcm sxxJsDpXw8VMaH0KUyyiSEyv+VXZjzI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KoQCMpcV; spf=pass (imf12.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677249936; a=rsa-sha256; cv=none; b=64E6k4ceIW92iL7sMS4MPFB6DfJsl+asJjmjysOzVgminNH5VsZ+QwmBXFSXzynm49SnqW OCbb/CP8lbQLoZY6gznAfc+gAmgZvVxzJMe5aHixtgEhbjL5azNM29vYv7J6O2Zd7c7LNz wyCW13zXo5viOy5UtgATKM4GhSJu8EY= 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 B0D54B81C98; Fri, 24 Feb 2023 14:45:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B322DC433D2; Fri, 24 Feb 2023 14:45:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677249934; bh=fsZo5UwngtiujtVaMFdBeRdGlqxmF8Eb2OgHfFLha4s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KoQCMpcVxBGblOpOBgvfaypZey0+18c7sdXqhZqkf7z00lk998aBoBXqOZFfIEXbx ywd2xWz2EOgQA3t7m4cKrX1mPZagO4XVixyI85s7G+ol8KMePibVZne3cue3kQhWhS CiNBv2YwXVaG4sN69CWSYgrKnjhetoyo9xMzaU/kPJzu3BnB/fLArG8iSH/Y35MiEn bD3DBougyxUQVPaOAYij8TV1NTWPVEzBoJudctn1ESF2BYVtZnq9lB4t7lpH5C49vm 5rccuAyAhaXwG43qJavnnJsxunEJxb3gyTpoyAzUfI7kYU+BPbYSy5nve3TXrhhHmj xpFb7sl3TD5Fw== Date: Fri, 24 Feb 2023 16:45:21 +0200 From: Mike Rapoport To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Aaron Lu , "Kirill A. Shutemov" Subject: Re: [LSF/MM/BPF TOPIC] reducing direct map fragmentation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: niif571mu59cgfoep7dyn3kweoah4c7u X-Rspamd-Queue-Id: 54AA440009 X-HE-Tag: 1677249936-439042 X-HE-Meta: U2FsdGVkX1+xQGrx2zol6ZxOPC8Gm9U2UkzcTjzWafAYp01tPOo2bnqL7zRnyVEr6guyXbToilGTKeQ/IqAJj6QEpJMntIFJv+nWqHfZxlMXwVjfih+AyOolIggR17jgd+qVa+WSZc+jdOr/c59dglZar4XSSmjLvhNPXzu1XZ+fxUK/NGw6y2zxUF+caRLLN4ydGoT2nKd2HtZBkftQPlUjt3fGdU8m9Npynt/qx76sfqUl/WFTDFl4lkbSZZ/qKpOL2n5hg7h1Ebz9mLTQf3+rIzn3tJ7BEJcZzJtPU8rF0AhIw8uI8qFWOGY0foFQPJqh2CseaeyYDnAK/FzD1cl187Xr2J0dzm2PwblwIJOtd+QP9l4dfL9AEXf/jluNB2YSqxaTb+8nFbIJtMYd3NU7ZPYndKt6EJkNW0ULe2yCxrRNJ+L2D48PYowY+avlJNFelXjxdOXvizWhOeG45oooSSVaH1DhioqyVNFEwHkObpKUfX+ZZnt6KEJfgXSV34Y7Z/cpGgMm+ues3KFWjx3DYeFUw7tHFo4wre77zxMI6qz+5uQoxD+AM5lPOENjAYUfncoWSC6xg+U0YzmzIPiUMtyXnp0gSAssFXreYtQfmF3knyEW8PFu7IJW1kZMeJ5lvRnA8VYizlXIXxhjvgqN/qu5SrzN06S3fOPNeZTqi+kjhYyqQyRkopAiehOhUQ6ITsKSNpddEzwVBpZO+IzcvxUmPj7eUpX7Cy1+l0E5AiTDKej5g0+owcAEyXC6xOtbvG5SftR1zSKb10TQuhteqa6MTkKkEaOy8dp+ez1Y1dTRBSCPbLVioozxnYddjWe/7KooWb+9tv/PylIJDf9wp55WzQwQnMsSDxemp5RnizQMvIYS9OaZgzoH0Zjd/4p4gHKJkAtRKjhwqUXwBDb0hqmSXNn5PqNdHIKvKlR4F0+n2g/JMeBbpKynVqL2nK4zT6qOWmeyg7o4635 CTcvBBeD QsT1ncliyJyWkPy0V7MidCX0MzInX0AKEhpsY0Meo9VPz67BZLyFSRPl5/UfnAzaK5NJq/4bq8SHezQ31re8hcUfcW50YpVjfK+8EmekOH7pjYr3PkLPHh1+2CVRVcJhGD5mqrgqEIR0yNDhFBQNB2hkZpX0WvIIyhUWYUpa42lUrYd2mgROxZ5jft73qkfY6fFGnCGNfK4E9V8AlqzR8sMYPxEisTbv67SBzP9cu/NXCLaDEKnl7x9DaMch+TD1GCTFWKJIVbqY3zZr6hmF3UP8YBjVmN/vbw6rCFlVHRqRJ+p4kK44cQfso09eAzzWGPhecwu7eafl9dr7vfz7vdlL5Z5HTwG7Zk8u8i+pZsLRwEKtQ58TtheCbgiF6gYYeeEsQreR/p+mZfvpRazDmxXt9+uKrXRbhGp6W7SRLnR8hlcouvkBz5gX6Mu3OAf0XXSS8SbNTPkSttgA= 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, Feb 20, 2023 at 02:43:03PM +0000, Hyeonggon Yoo wrote: > On Sun, Feb 19, 2023 at 08:09:07PM +0200, Mike Rapoport wrote: > > On Sun, Feb 19, 2023 at 08:07:59AM +0000, Hyeonggon Yoo wrote: > > > > > My current proposal is to have a cache of 2M pages close to the page > > > > allocator and use a GFP flag to make allocation request use that cache. On > > > > the free() path, the pages that are mapped at PTE level will be put into > > > > that cache. > > > > > > I would like to discuss not only having cache layer of pages but also how > > > direct map could be merged correctly and efficiently. > > > > > > I vaguely recall that Aaron Lu sent RFC series about this and Kirill A. > > > Shutemov's feedback was to batch merge operations. [1] > > > > > > Also a CPA API called by the cache layer that could merge fragmented > > > mappings would work for merging 4K pages to 2M [2], but won't work > > > for merging 2M mappings to 1G mappings. > > > > One possible way is to make CPA scan all PMDs in 1G page after merging a 2M > > page. Not sure how efficient would it be though. > > That seems to be similar to what Kirill A. Shutemov has been tried. > He may have opinions about that? > > [3] https://lore.kernel.org/lkml/20200416213229.19174-1-kirill.shutemov@linux.intel.com Kirill's patch attempted to restore 1G page for each cpa_flush(), so it scanned a lot of page tables without a guarantee that collapsing small mappings to a large page is possible. If we call a function that will collapse a 2M when we know for sure that the collapse is possible, it will be more efficient. -- Sincerely yours, Mike.