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 7E0DBC433EF for ; Tue, 1 Feb 2022 19:08:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E0938D0081; Tue, 1 Feb 2022 14:08:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 090F78D006D; Tue, 1 Feb 2022 14:08:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC1AD8D0081; Tue, 1 Feb 2022 14:08:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DA8E48D006D for ; Tue, 1 Feb 2022 14:08:43 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 83EA480EA450 for ; Tue, 1 Feb 2022 19:08:43 +0000 (UTC) X-FDA: 79095147726.22.8D3F48B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id EC40614000F for ; Tue, 1 Feb 2022 19:08:42 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 1DE7561618; Tue, 1 Feb 2022 19:08:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C67BC340ED; Tue, 1 Feb 2022 19:08:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643742521; bh=J60T+hp80IqgCqMZaaUwCXExSpnAXsfKJj4XaVPNPp0=; h=Date:From:To:Subject:From; b=negdrmVQ8inc8SCXxNGmICUroxRPDYewD/44Igf0c30QKc7i48S7DB15VDRr64wN6 S/9JzrdcN9d0tTuX6hSPCRmWxh4gn9qzveZiQ8aqZwChTvtLy/UajHTDiDH6NMJDJ9 AScxVTwAlsHEN0QkziNFl+mfC6PBaIU/fTMMwzcvvbBrTzUAUMqmJ0/OMQ6r86iUh4 Iro7TIpu7gP68IQcHX/aZ6gW47N2LtXCT3IlXFf2TNGRdd+ZrhITRlMws9zb2qtrmT 4PDZPLAUbGxe7ORRVgWAHeZQUcqohgstHGbvKe4SqVd2HJudzblCDOKVVjNz/9Womd sDhsgsBe28+eQ== Date: Tue, 1 Feb 2022 21:08:34 +0200 From: Mike Rapoport To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: [LSF/MM/BPF TOPIC] Amortising direct map fragmentation Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Stat-Signature: rgkm4yb51uguynqnn9p46mrus61bq9w8 X-Rspam-User: nil Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=negdrmVQ; 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 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EC40614000F X-HE-Tag: 1643742522-887521 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: Hi all, There are use-cases that need to remove pages from the direct map or at least map them at PTE level. These use-cases include vfree, module loading, ftrace, kprobe, BPF, secretmem and generally any caller of set_memory/set_direct_map APIs. Remapping pages at PTE level causes split of the PUD and PMD sized mappings in the direct map which leads to performance degradation. To reduce the performance hit caused by the fragmentation of the direct map, it makes sense to group and/or cache the base pages removed from the direct map so that the most of base pages created during a split of a large page will be consumed by users requiring PTE level mappings. There were several RFC postings to address this: * grouped page allocations for vmalloc permissions [1] and for PKS protection of page tables [2] * pool of large pages in secretmem [3] * global cache of pte-mapped pages close to the page allocator [4] * a new migrate type to cache pte-mapped pages in free lists [5] I'd like to discuss the direct map fragmentation issue and the possible ways to reduce the fragmentation and performance hit caused by it. [1] https://lore.kernel.org/lkml/20210405203711.1095940-1-rick.p.edgecombe@intel.com [2] https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com [3] https://lore.kernel.org/lkml/20210121122723.3446-8-rppt@kernel.org [4] https://lore.kernel.org/all/20210823132513.15836-1-rppt@kernel.org [5] https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org -- Sincerely yours, Mike.