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 56893C61DB3 for ; Mon, 9 Jan 2023 19:11:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 839498E0002; Mon, 9 Jan 2023 14:11:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80FEF8E0001; Mon, 9 Jan 2023 14:11:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 726838E0002; Mon, 9 Jan 2023 14:11:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 621488E0001 for ; Mon, 9 Jan 2023 14:11:42 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 335BDC096E for ; Mon, 9 Jan 2023 19:11:42 +0000 (UTC) X-FDA: 80336204844.16.7EB57DF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 2CAD04001C for ; Mon, 9 Jan 2023 19:11:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=B7xkeaLM; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673291500; 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=rZnADjZWCjTW5Dm5RzZIyObRUluJDQrQlpKex5eiA1c=; b=nNDIOF1AKN+ou0QnZoiSTgjakXv13tpqOhuhVu/3mNFjHeF93f2fRhcvPsQ6cOSBHpTud7 ueU9xEddP9gOa8CTSoOUuxo9Knji0yQVXdMZSy5VVmmm3/vfspIBqifQWIRO8EJXPwjMFN JWyZ36c8FWgLna7VAbd+rOIuGnpBRU4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=B7xkeaLM; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673291500; a=rsa-sha256; cv=none; b=Ua6Qgd5tDeuSxs2hs2n5X27v0Mq7bzG6dg2McWQ2cLo8AV8NyOfPx6EMaZ+oK8ktsnRjKG yhQaxqUhIt91eUTIb0zcOjmT/o8qBbXOPIFbnasjvrcyokQyvmeglf9llTry851qS5Boy8 /XkJlvXwW6pBFb6w/OddmbufFtgTASM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rZnADjZWCjTW5Dm5RzZIyObRUluJDQrQlpKex5eiA1c=; b=B7xkeaLMpZjckBvj1NVX6bCcf9 kF+xd4pjwzWx05/iFNbByXBeCTvsiBPh9kBdrbQPgGTpxsHM9zU1xmL7+8hy7UYuoussCZ7ePMaMx CAznPuXlTrGbcB105qMXEWeEsey27OyJYB26KG2X4afN/f35k0xIxmvGaxXEzPsRE5vt/BbT+ZSpg f5dlT8+puugAYC2M2GTNRk3QZMZVEwMy0q6l5C2c0Ou++GUFDc6iyXx4GIlhrrSB51peVCzkDMMZ9 x6dDYXkyGaMcWptyNp+lo5fTIT2yTSSZyol7v3sgml3ueoSfcsjxptupDWgrugXiqDm/R7poubAnF XyGzUcxQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pExYO-002YYO-Kp; Mon, 09 Jan 2023 19:11:28 +0000 Date: Mon, 9 Jan 2023 19:11:28 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Yin Fengwei , linux-mm@kvack.org, akpm@linux-foundation.org, jack@suse.cz, hughd@google.com, kirill.shutemov@linux.intel.com, mhocko@suse.com, ak@linux.intel.com, aarcange@redhat.com, npiggin@gmail.com, mgorman@techsingularity.net, rppt@kernel.org, dave.hansen@intel.com, ying.huang@intel.com, tim.c.chen@intel.com Subject: Re: [RFC PATCH 0/4] Multiple consecutive page for anonymous mapping Message-ID: References: <20230109072232.2398464-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2CAD04001C X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: oqhzcsks4aag5uao15gwczruhbkbdgsk X-HE-Tag: 1673291496-396311 X-HE-Meta: U2FsdGVkX19m1ZLU9tTP2TflG2isDCuZi7VGRc68Ioz8JEckdeYM2T9dULwUS9Ol4lBPXsnDIaFDt5Js+29htgqB+ipJH8G4uuVTbSwKi4LeFeXFCHFYg7lss/s1wfqn+POumTIB8in3tZFcK7nwZzKY5SnfTcsv9UvtepI74lzD1wjr6ctGLnFne4IcwiEKr/0hHLMTA8G68jRoA7sajkrBc11tikv5d216XN+EkU8s2d60pZRv71A/XBBz7WBYqeuwVGho1lK15k2WR1sr5OvnF1Bp4jRQdWfYkhDjityKNBSZCZsuQiPikjke2Fiv3KXgRIMeQGXSl5PNivcxlsu0tNsheSxlo7TlxNaxJuBasDYIutfSmwXFM+3NAdyh/A/w7t36v6XJczuU7TZTyC3+e54EiRRMmoYe79acIQ885xxSWvUxeMg5B4dpv6amGVWNqnVEWb3Tk/brTKJ4CogjyQRHnuTDS7tskoNLMLk+wXQFNgt6Rztd6ZQqeWlXbHSk95OuOTkE4h57R3O14tmIOpBCVpqa9pmAfnkl/tMKQ2fFcTIaJW8hVJ7E5MEld+HsNDQnKDNF1qkGrDAhnnFpN6HjN74DFvqeKs2xISbA+i50nCKviUMy1YuXt6vAo5hZLgU25yzhVsKsjGlkCzS71YAWtCApg7ocmBXc5ZV2facMxJY8HZK0r/MPbQA33SRTOl+YaVPo8g8pKtNKgh3SWct67vvQG47XrUw8zCucLH3uqBgZd+8TQ41ybIKil8P1LnSMGg3p3UHhrhEpNaT5sb3KsGBsrRQLvSbAyrg4qnXUhMTRVvMek8bKKF4gzZne2EQHqPD0ID/lT7Cn0yVUELoc3SYuGYV204QvNSk= 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, Jan 09, 2023 at 06:33:09PM +0100, David Hildenbrand wrote: > (2) This steals consecutive pages to immediately split them up > > I know, everybody thinks it might be valuable for their use case to grab all > higher-order pages :) It will be "fun" once all these cases start competing. > TBH, splitting up them immediately again smells like being the lowest > priority among all higher-order users. Actually, it is good for everybody to allocate higher-order pages, if they can make use of them. It has the end effect of reducing fragmentation (imagine if the base unit of allocation were 512 bytes; every page fault would have to do an order-3 allocation, and it wouldn't be long until order-0 allocations had fragmented memory such that we could no longer service a page fault). Splitting them again is clearly one of the bad things done in this proof-of-concept. Anything that goes upstream won't do that, but I suspect it was necessary to avoid fixing all the places in the kernel that assume anon memory is either order-0 or -9. > (3) All effort will be lost once page compaction gets active, compacts, > and simply migrates to random 4k pages. This is most probably the > biggest "issue" of the whole approach AFAIKS: it's only temporary > because there is no notion of these pages belonging together > anymore. Sure, page compaction / migration is going to have to learn how to handle order 1-8 folios. Again, not needed for the PoC.