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 98CF0C7618E for ; Fri, 21 Apr 2023 17:14:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2986D6B0071; Fri, 21 Apr 2023 13:14:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 248A06B0072; Fri, 21 Apr 2023 13:14:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 137876B0074; Fri, 21 Apr 2023 13:14:58 -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 013E56B0071 for ; Fri, 21 Apr 2023 13:14:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CA9CE140896 for ; Fri, 21 Apr 2023 17:14:57 +0000 (UTC) X-FDA: 80706048234.07.9AB38E3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 64BBA40020 for ; Fri, 21 Apr 2023 17:14:54 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=XW4oII0O; spf=none (imf07.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=1682097295; 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=AtvmO0xGmo7IvM4Hiwzxf0iWjctxbr+KbWVfxmqqbpw=; b=K/HIJD6RP1DV91YnYIX/X4iCeNxtesXXi94i1EuIToBDL7kfsKT18IcJ40Brm7bafx75rV 6a8usMsC3MpG0H7Ma1hdq7afAtzwkXOOUTRRuwQR1gg3Xur6mMfLc+0W5/VrYQdtZcAOl4 20Em1OJ+3ImRquSyFe+UyQbnu5lKSkI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=XW4oII0O; spf=none (imf07.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=1682097295; a=rsa-sha256; cv=none; b=FiexFWBvVBv2E4NxGhYtKztOqLki8CKEBEvYGnjWfKn/FyJ44BewhskdZnvMlGfIGUETIq 1Q5sLjyMVbTjjxqB1U6Wh4Y8ghrqKJzCCvpUJCbdNFU912LTmHcSdQp3rVjHd5lbbEFMWz PPLiY4uwaiehQOTNiPFEuXwWAu1GGek= 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=AtvmO0xGmo7IvM4Hiwzxf0iWjctxbr+KbWVfxmqqbpw=; b=XW4oII0OralIKyM9phqGrPcDcA 8wYmtVd4VW+lvJPATf7K1MSjFcz09leqd4DPDTvsL47GEbXQ5wl6AWrRrfw98Tv4ltULf88th5JoQ 7UnEkakK8cfuMk+E1pTHmDEPMLdS88PbXjJTDdnUB/mzPORk0ZpSVvDyktDC1opIOM+DQKSpmMO7c crni9qfeNnVe/iCP10Y4khF4ylh61qgKv5ELwJTy4D6g7glkRhAkrQniQCy7+3Y+SkCEMTWf5Mvil yDKZPgphuZbPOECyzvZE8W1pD7xwc3273QUKog9Xe0RMzBBxUSE3qCo3EcvyHJrdmocV3iMsFgdMA MI+8Cw6w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ppuLJ-00FRSI-EX; Fri, 21 Apr 2023 17:14:41 +0000 Date: Fri, 21 Apr 2023 18:14:41 +0100 From: Matthew Wilcox To: Mel Gorman Cc: Johannes Weiner , linux-mm@kvack.org, Kaiyang Zhao , 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> <20230421161156.5jnipnfs4svwwzee@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230421161156.5jnipnfs4svwwzee@techsingularity.net> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 64BBA40020 X-Stat-Signature: iuoupcczdr83ddog7yej85aq3yw9jbyo X-HE-Tag: 1682097294-243977 X-HE-Meta: U2FsdGVkX18Nn6nl3FMEICQPbh1Au+2aqis99v5yf6cZHuauI3JQkogNPvQf35Y7MqRD1qpfg1Mmi+YXK1zN+0JGULh6lssfwWneDLJ1nVCM9FlDobhnmcQiwvbHmiY32rY8Y9Ys6oXngotDAK8L9vVB4YkgECx6bZM3NqgFPyvW2yoYxuvI/m5jZpl3nLGfchGWg9wsZcvghET79al4zUE0cyBdoKHeuQWgMJGz1j1IP3XRAd4dVJB29bGNgIWNSCltNPDcCaKVwG2CnAHfdrA5/B0w2dsTTsvpNDp+FsGB7k734kQpw4ZlNWVpqYwGga9qjxoRa+u1uTd9Qk0gZ/3P/PHNacIfkNC4AREXpqVOOPDCI7KEwgLzLgqGRtqz/yiQm3LJ5mm4iBM6SXoED8MVrnYUHywiU2VGUPCEU0QA+P1O0uull958s7tAZnYv7n0nPYJX3HGsMNMkKDIOuFAeMLKfdIweexInN4EP+Xj1kjx0r6OVhcwU30qczqUt/A/wUFFaFYqdhUbzta8sAJZ/TnlYI2E6lSZVVsduSEA+EtPFETB8oeMi4iWryk/8XjgrrmrtC3SLi+H7VrOp1tKIqNeMbsIyj2TAW06mJn+RwjH96Q4O5YyYlTkYjQrvyBx9eJUuT2Tp+rYOLsum2B++sHZNQDajXXikR97sv9XD+gpLlhTEbOXEt2orZdRwUklqU/tKJEV+aTFcFcYur/rv0SwYSEyB7F2MO5RcT6erBBE3xYLLw/mwH/0BZyRr/wan8rAt82egFR/+c+8lDeQQLWxWCTjsPa7ItE3Ug/zldID/MI2Z5bBVPHsi/mcQdFO2SyC+//dn0FeM/dbNR2BQQw6/Yvji30Afs+7I9dYmF8WQiju8TS+0IXn+BKBRmtbDOd1Vn5+4wyITdSUvMLiSsDg2O7h5GljbTru08eHaWdJEpvG83XYi6+0Yo5VASqfI6cjIDH3L91gquhb kTknj47Y 5PQZwmp34GypSdyMlKWpxYhWmp5VAZtQyFpmAGYdL5p956FwT2Noqm6OWzDbjKDsHuCnyzXp3wrt5qpOH3XONFxChGPrPnyNO3rCBECNyM7UFha596b96ngr2aEnexiMbHBLadUykyRWQvRw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003355, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 21, 2023 at 05:11:56PM +0100, Mel Gorman wrote: > It was considered once upon a time and comes up every so often as variants > of a "sticky" pageblock pageblock bit that prevents mixing. The risks was > ending up in a context where memory within a suitable pageblock cannot > be freed and all of the available MOVABLE pageblocks have at least one > pinned page that cannot migrate from the allocating context. It can also > potentially hit a case where the majority of memory is UNMOVABLE pageblocks, > each of which has a single pagetable page that cannot be freed without an > OOM kill. Variants of issues like this would manifestas an OOM kill with > plenty of memory free bug or excessive CPu usage on reclaim or compaction. > > It doesn't kill the idea of the series at all but it puts a lot of emphasis > in splitting the series by low-risk and high-risk. Maybe to the extent where > the absolute protection against mixing can be broken in OOM situations, > kernel command line or sysctl. Has a variant been previously considered where MOVABLE allocations are allowed to come from UNMOVABLE blocks? After all, MOVABLE allocations are generally, well, movable. So an UNMOVABLE allocation could try to migrate pages from a MIXED pageblock in order to turn the MIXED pageblock back into an UNMOVABLE pageblock. This might work better in practice because GFP_NOFS allocations tend to also be MOVABLE, so allowing them to take up some of the UNMOVABLE space temporarily feels like a get-out-of-OOM card. (I've resisted talking about plans to make page table pages movable because I don't think that's your point; that's just an example of a currently-unmovable allocation, right?) I mention this in part because on my laptop, ZONE_DMA is almost unused: Node 0, zone DMA 0 0 0 0 0 0 0 0 1 2 2 Node 0, zone DMA32 1685 1345 1152 554 424 212 104 40 2 0 0 Node 0, zone Normal 6959 3530 1893 1862 629 483 107 10 0 0 0 That's 2 order-10 (=8MB), 2 order-9 (=4MB) and 1 order8 (=1MB) for a total of 13MB of memory. That's insignificant to a 16GB laptop, but on smaller machines, it might be worth allowing MOVABLE allocations to come from ZONE_DMA on the grounds that they can be easily freed if anybody ever allocated from ZONE_DMA.