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 5729EC6FD1F for ; Sat, 25 Mar 2023 06:38:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE7DE6B0074; Sat, 25 Mar 2023 02:38:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E49AA6B0075; Sat, 25 Mar 2023 02:38:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9C86900002; Sat, 25 Mar 2023 02:38:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B4BC76B0074 for ; Sat, 25 Mar 2023 02:38:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 81797C010C for ; Sat, 25 Mar 2023 06:38:30 +0000 (UTC) X-FDA: 80606466780.03.F1E30D9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id DAFCA100013 for ; Sat, 25 Mar 2023 06:38:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UKFHkzqy; spf=pass (imf05.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=1679726309; 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=xPBEX0TCo0jB0IpN8qDSJOBgn1N8t4YcIyJYCtEEVBc=; b=aZmFjddwt9h39A30EdA7cyHHHZxDhNq3cnF9BAQRvG9xAHkN8hdSKf7SVEFSwz9wuYgP02 BQXtcT/nfzWE0QBZxXvAcdcRkYKAkzXuPJY93pypRmX19yOlv2awBWvO6XwzEutMDgKY+y fAyGx1qhchh8EV/+kIilkarKwgO5YnE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UKFHkzqy; spf=pass (imf05.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679726309; a=rsa-sha256; cv=none; b=Yr1z4hahORejaeJzPL0Y7kvH41VKECjYM8IPN8ufI9EaI/Xck9aj9l/JkntfH/V1l2Yg4k siFgZIHg7j74q9NuxP5s2SfuJtkDMsC+ydmEHBKhiVez6iIxYn3bLgM/KwHB3YyaBr5Da7 5IFys42sVjnZSAIWws/7YDapBiYAsEE= 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 E1EFE60A56; Sat, 25 Mar 2023 06:38:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98850C433EF; Sat, 25 Mar 2023 06:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679726307; bh=09X3GwvaX9EPrUeSWfoBHO3NT20VKgRC9q168x8HVao=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UKFHkzqyyxtLu3o9NPWBgip+PXHpiM8d+nMz/dKNC4zOyJrzg+tIovoeIrsJd8vIV Rh9GTHvBrgxJ6HaGKZ4nsyRLv1Xm9I36lai0Hp47sxibC4juLYIKEtZW4qFoogvKod IKS/UxNUjS/a6oLpL9FPf0h3rcbMxBKi0+zP63GWVCBWUS5+2RYnlofMRYRuM5Nz56 L6YYH4giJklgskzrLg3t5m0RAwv5Blzjc4qxh+w+sEyHuoa0h4B0sx2WqtV0vscVBf 1lQrHfCYU9GSa+Qh1NhDcdglo9JEyjAyCOvs0rdLM61SWMEdUlC0egL7IRyU+QTfIM dDTKS40iyIC8w== Date: Sat, 25 Mar 2023 09:38:12 +0300 From: Mike Rapoport To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Song Liu , 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: References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DAFCA100013 X-Stat-Signature: o4hzsuma9nokc1f77ku7ysg6fe6rzuz1 X-Rspam-User: X-HE-Tag: 1679726308-617224 X-HE-Meta: U2FsdGVkX18AARMr1wtZg9K2BWDrRpysgU2QwjO9wR/VMxLcSP6gpWTeu57WSChh1H9YAdbXF+8jtFa5lWH7/Vn8dg8KaHan+c2bq+U7bJIqHJ1zfRSTipnCrcVGt0I1EMu+A22mTetG8iA7pdeNw6N8hXVDDESpXgbZQiM2qOw9vlTChSzHi3hxQIVR9OQERt56qdbZF9LbrAnP99GfawfTw0Kyqo3nCiS/YZDnuN8lGjtc9ymbTN5wx30M06MmzlQysxhgJ8kM9EesikVmj9yPDMIsN4pzr2DPyGmWyWqL0nqMVuSkIq2w3ka0lbc70+vvcx6VGaD0+oQmI0rPWElzO6wyZkKyEu+oNvQH+F+6JN0/yxeXFBK2DhY8hZfR2mYQlN2E4vOoJW4M6Mz0v2XLm85ANiAs27YQfDT5AymowiUgEJ1Uqnj0zGdJ21gKwEY7WGPDekVVhONvgOhn+aIR3z1iAHMR5wT2S1qn+s3SckaXr/79evIQ8ozxumuYRQOPnKCCaV7XM4JKAMN1BsSiTtKYiXBCYQxojpqqaroRlU53C1y6p8LJv/mgSLvlHjipTaFLDa0tSXZUdhcO+Wu5C3urbkO2JNYAVDU/O/KrkfPk39qtDw3Lq163L1dDgdwZLZ1jeDhCb2O5/8ZTtIx7MpfbudA9LfIGLr0gL0k4HNClhQgtcJ6PPv5FM12m04gm7VMXFT/5JbVU8Lp0X9lM9Y1EPigkgqGL/sDnWw+bohxWpVebuXr8HT4LLI/YKuxBSxmE+lsvLqlqvAQdwvvWl8Ccz9aAY36qx0J9HbG65WN8hFTaxOSU2ZSWWW49FDVcJx5z3FOpb0Tlf7GaluU8WULuSJ1HLXz/8a7QVEy1vFQzeznD7pQlnYlc5hju+7XXPkh9ej2Ld8oy/DbQoFzNiqkmzY5WCx++IimHcnf55L/bzhGzRz18+3bBIKLQhAYAXq3e1pIOnmZZqY+ iTpZXVEE aP5hMTqXqSHns0OOyCuXTPe8/ytUJ/QHrK4mVLHdT7j9v+x5H/CvyvAUHsTaJSSs0RmBjBjwqKF0Oor+dL2SwCOzD82iXeI3t39MWDiBr5lbTHGAYk8b7IcubS5ZBQSZsn6SdfIFBZbjJVqOYleW2cUK1/cprPcwIGrb8CsR59WD23erisDDnzSmtDtjuSs9VHXx5VfgFMPfkrFGIDGrA8dI07vW0ikk8sG9aIX9g7olmR01xMafCzT+8ommMb0PXDX2v3J/h1zfBmmz4Bcjpt0nNYEw4c5DGSFjk/3rU8nOchjP+TOutQWAyGUDHcsNBOeZJeAkNG0emE4niGOc4cG9JQ2wMKnLdkTO3Q9cYLE86u6ZwHmeAXp3CdYeRo7qYXTYzjPDrRG3VA/UpGpC0dfp9Xi9hOgrdMjXm 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, Mar 24, 2023 at 09:37:31AM +0100, Michal Hocko wrote: > On Wed 08-03-23 11:41:02, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > When set_memory or set_direct_map APIs used to change attribute or > > permissions for chunks of several pages, the large PMD that maps these > > pages in the direct map must be split. Fragmenting the direct map in such > > manner causes TLB pressure and, eventually, performance degradation. > > > > To avoid excessive direct map fragmentation, add ability to allocate > > "unmapped" pages with __GFP_UNMAPPED flag that will cause removal of the > > allocated pages from the direct map and use a cache of the unmapped pages. > > > > This cache is replenished with higher order pages with preference for > > PMD_SIZE pages when possible so that there will be fewer splits of large > > pages in the direct map. > > > > The cache is implemented as a buddy allocator, so it can serve high order > > allocations of unmapped pages. > > Why do we need a dedicated gfp flag for all this when a dedicated > allocator is used anyway. What prevents users to call unmapped_pages_{alloc,free}? Using unmapped_pages_{alloc,free} adds complexity to the users which IMO outweighs the cost of a dedicated gfp flag. For modules we'd have to make x86::module_{alloc,free}() take care of mapping and unmapping the allocated pages in the modules virtual address range. This also might become relevant for another architectures in future and than we'll have several complex module_alloc()s. And for secretmem while using unmapped_pages_alloc() is easy, the free path becomes really complex because actual page freeing for fd-based memory is deeply buried in the page cache code. My gut feeling is that for PKS using a gfp flag would save a lot of hassle as well. I also think that some of the core buddy allocator code might be reused and unmapped_pages_{alloc,free} could be statics in mm/page_alloc.c and won't be exposed at all. For now I've just copied free list helpers to a separate file out of laziness. > -- > Michal Hocko > SUSE Labs -- Sincerely yours, Mike.