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 C63A7C77B73 for ; Wed, 19 Apr 2023 04:11:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 339958E0002; Wed, 19 Apr 2023 00:11:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EA378E0001; Wed, 19 Apr 2023 00:11:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D83A8E0002; Wed, 19 Apr 2023 00:11:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0B9B98E0001 for ; Wed, 19 Apr 2023 00:11:50 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C7E41AC3EB for ; Wed, 19 Apr 2023 04:11:49 +0000 (UTC) X-FDA: 80696817138.17.9EA8C84 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 30B3D180011 for ; Wed, 19 Apr 2023 04:11:47 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F3Mm3Lps; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681877508; 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=fCirft2EQ+qvGc6ZahSkKa47nK3OVYtgm30zMVksWYc=; b=mPqBLry34zE3/54aGVmhQmgzb9AYl0nAZlFphnQSf9UgLopqIzVw0HKdp8sMUKGCgzOoJj qlr5FTecW/cm6W+wQ8GcRvAYONMs4c9SxHnUwqFoIDFPkHPVePOHJDWIbgjSJ/fwQraPiI qLD/90W3l7EWUc8nEug1Ob2PsUe73xQ= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F3Mm3Lps; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681877508; a=rsa-sha256; cv=none; b=vwEFOKqj47G3HHfIzsGRMIqKPfJZUxoNzxfQ6iwyquDjBoCveuGfY/kh7Zdh1+mYl9jprr ev8KQ7VLIFiLWkcs3c0Y6uOsIyFMJ1ECnVJSy10my4+V2g3t5nKPz90mZT+l7YG5/0Ubox Or24vcO40CVyVqb3kqg9rqbAXAXQWt8= 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=fCirft2EQ+qvGc6ZahSkKa47nK3OVYtgm30zMVksWYc=; b=F3Mm3LpsRGSooA3ZUYSX/vadVw EshdMvO850KSZucpjBZNG0dxxMQ4GcYMsf37mR31oDQ3tChovu8d7vEWh+p/dTuE+de3LbPSHWX8k GZ9kFmHyWUiylFE1d4OH1/2uZCDlJMtFCN8ZVXpZf67VXzFMtZ8vp7IxgCNtNx9sZJeyW/qY/S/R/ Sgr3SNuJbsuhYpmmhqsOe3q5CGP29fgV7AkWR6RuOwpavFhcdRL6FGLPLbtU762JGe0T83XrVpnT4 dasscrClOZkYmjmUUM/9bJNkupRhq75tUoquhJpA4kUP1wh20nEqSQfjnq3o2Z47sOZwwl1glhsU+ pM5XMY4w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pozAX-00Cwu9-Co; Wed, 19 Apr 2023 04:11:45 +0000 Date: Wed, 19 Apr 2023 05:11:45 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: linux-mm@kvack.org, Kaiyang Zhao , Mel Gorman , Vlastimil Babka , David Rientjes , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [RFC PATCH 00/26] mm: reliable huge page allocator Message-ID: References: <20230418191313.268131-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230418191313.268131-1-hannes@cmpxchg.org> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 30B3D180011 X-Stat-Signature: ikdkumaawqxtk6mrxb4mhhc8xrtftx9h X-Rspam-User: X-HE-Tag: 1681877507-182421 X-HE-Meta: U2FsdGVkX1/AwIkNskhRGKeo87RvSdx3RxBSNHeyGxgORKRau6gb9u+cHjXXOMeqiomPpKW6GH2FYSYOymY7I4qmRx48xMHqtwyzjgQndGsrQn7eeqzwoY7pGw0ugmdtCO9Libv+HiYLXLH9feUyKtje9Z+QegBh0ZQhXLygNpNjVHm/l96ao3NF9JyONC3ZYeIfTC78S/7g8J2YDiD++ScTCkq+gLgDhCuQV2PMDa57sI94BNK8w6KWUcuE9C7bmhD5TMQ0T+xVL1jaIQXMaXhUM0aEnzLlF/xzW7ncLEZ95aIq1eIMYI/g3xO+vEXiV3ZaoevHlsS/wTev1y5FA5fKzuOi0EBK9PI6qvT/WsIVjrwlJWKNhOuFELvDw/jQk90EQqIqQa1j3lrRZCq9kcC41+a69oauZXXAyDG+uBbA+lAnfNk0/0kt/sGR8DNvec8MRWUZ48eYQQSsgiXe1V3MQA8FmCNHr3h0aNQcFX04vtWzgVamBcRmARefX8GuU5nrIoLsNOBRfhvCSNYNd0urgOUoaPJyiZ2pJ5ujGad4uNAwESnMdrzSd6cWjDt9ImiFHrqrnZu6/BJSCxaxZb0izAYbtCo4NUOEOHKr6ZxsqDnA+AjQNl0nQKf/RVPMsoix0po8ZEGKoG/1uFbzKVMEqOAgXLABluhchmIHX3SSb9gcqFqnZP1tsyi51uawRNJuxml8gBw6EGcWRH4jFBBOSKuOzMZs6eAzGAsU3t/7vIssVVCjTvpYsxu4QTMb3sAYR5n27n9gfaqkbHwHm1CnMTkmIyOSHyjHRyWxPW5qxgudSWubSrhm0KsxOQ43nWhHzj6sxKBMQvCnWoNKivpPqmWppKkRvde+4uI2bFYGbCfmxnY7zP43T6ePnMS4kZdSFPtjcL+b5/2At0V78zPVrWz6qoxWxn6KbakISV/fcZU5s6NlfiYXW5F/s+/LzGo6C1x9+mCBOn5ON29 3CEpNIB8 n/SxbbjpnZqD6jFtYNIS3GCLVou3oYzMB4v4l8PSVVc3r+Nqx4tlWSFaeejK7mVFx7EOO6/2E+1dlNm71iKbycxat6bocx260AwP5WGMEw7RAw0+bgRynOjJ1OE0fogSepiXVFTFyrkLStquDEOmL7V2kpg== 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 Tue, Apr 18, 2023 at 03:12:47PM -0400, Johannes Weiner wrote: > This series proposes to make THP allocations reliable by enforcing > pageblock hygiene, and aligning the allocator, reclaim and compaction > on the pageblock as the base unit for managing free memory. All orders > up to and including the pageblock are made first-class requests that > (outside of OOM situations) are expected to succeed without > exceptional investment by the allocating thread. > > A neutral pageblock type is introduced, MIGRATE_FREE. The first > allocation to be placed into such a block claims it exclusively for > the allocation's migratetype. Fallbacks from a different type are no > longer allowed, and the block is "kept open" for more allocations of > the same type to ensure tight grouping. A pageblock becomes neutral > again only once all its pages have been freed. YES! This is exactly what I've been thinking is the right solution for some time. Thank you for doing it.