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 01147C7618E for ; Fri, 21 Apr 2023 15:24:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 644006B0072; Fri, 21 Apr 2023 11:24:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F30A6B0074; Fri, 21 Apr 2023 11:24:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E19F6B0078; Fri, 21 Apr 2023 11:24:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3AD856B0072 for ; Fri, 21 Apr 2023 11:24:53 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0C29E120459 for ; Fri, 21 Apr 2023 15:24:53 +0000 (UTC) X-FDA: 80705770866.03.69C6BA0 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf02.hostedemail.com (Postfix) with ESMTP id 39D5180009 for ; Fri, 21 Apr 2023 15:24:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2Koj6mzw; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682090690; a=rsa-sha256; cv=none; b=0gjtb/HVPWfSAoVuGAke1CjFlBaVK1hMPbF1z+CkADPQBLBw12pLWR8e3tYrn584YARRkD bWSLxGAuBmtq8MXpRiDmj7vjUOdMPZhYXCMr+GHNzB+6NsKEQf+vErDKPVr+n+Zz39sN10 bfONNBPgdqvZbupS1w/WnK/NjkXny3k= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2Koj6mzw; spf=pass (imf02.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682090690; 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=RftFvtCXSnbWL3l9VrIM7QoXKzHXMSCTPiXt889YEl0=; b=Iz1rQye+c0i3Bm7pPvpGHbIMaPFjxqOKB3KLaCz7yKcIuEqwBwJw1MOfEsFslixJthnGHQ RllaGmDqHdPemEBsW5F+Qxe6BK/T3BHx1sslDLOB8lm1rFks6C+v27fOTgbGHf7FMKhpHD 4I0ZDdE/m0Fg7lF/oRl3FlEBI+gLKJA= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-3ee339e8c2fso10223311cf.0 for ; Fri, 21 Apr 2023 08:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1682090689; x=1684682689; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RftFvtCXSnbWL3l9VrIM7QoXKzHXMSCTPiXt889YEl0=; b=2Koj6mzw3RB+sbrzYnqnCKjrjNHpKSVBtvarxtDPzVtew+23aLMKQMKePtcp14DQmb PwYLmSeJce+OF4PU8/+dKX00Bia/q/LBbQ9ClaqyBbhtT+qXbhcKkE5VRiZJhJNm9nRa 5y0VGmQlMXLhnXs7OBbgHqowKSWj9OQO4LKUbYNwE4djSFPOieKv1Guu0rHbzXtJPsSH XW8ZJUn0W8O20HSkv7qKX+yhb5b8N4dNAdvt4zGMujMewOhpIpfYU5HhJRycj3vaLfpy FigyJpT9bbXeFhKBt6LsRN1q/TlsGfryYW9NbY6EgcHDv0fAwzbTtdBLbpcFyc9IME0B fEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682090689; x=1684682689; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RftFvtCXSnbWL3l9VrIM7QoXKzHXMSCTPiXt889YEl0=; b=h23vlNadyqln4gYbvbuSrkSMwFvfcImOfWdrAV8r+aH2rtkEIi5NdqnxXeI8DyW80B Nx1bnJAdJxeffnGHUMROSsNG2mcIAxGzKmcbclV9qC+9QXswqo78dd63Iws2FCidcME+ so0XUGs3u+yMCvfbW7iAKII2xgRblynsIlQ2h2f8FTaJE9EsxIR4LNajlEk5GlR5BxSZ 7PkRpjcbu6byfOSmlBetLOCx3tFMPmMpIe+ae3sdxp9zEiD0Sn9axeTSpIcpfqnS1vC5 t+RUQqA3wIjitGLILH1167G4eTjosQzFJ7S14sbovVFG0uPQdUeX9LGSaDp6sRnLswwY /juw== X-Gm-Message-State: AAQBX9fbJuCo6me6VflYY0+k7c3GBgIioOnShiXKXBBqpSK0rFHuVmhP kFcw+to24U3ulB+WPydHhLnWu0JpM20vF3wbWXE= X-Google-Smtp-Source: AKy350YGwgWA7VkCxUROUCL59NSexIgVNi4Dsmr1wFDncC6uDyg04UVnatGNxweGxP/q5UaRc0mMWw== X-Received: by 2002:ac8:5947:0:b0:3e4:e39b:357e with SMTP id 7-20020ac85947000000b003e4e39b357emr8591422qtz.44.1682090689314; Fri, 21 Apr 2023 08:24:49 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:6f0d]) by smtp.gmail.com with ESMTPSA id j18-20020ac84412000000b003e6410b4bfbsm1382312qtn.28.2023.04.21.08.24.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Apr 2023 08:24:48 -0700 (PDT) Date: Fri, 21 Apr 2023 11:24:48 -0400 From: Johannes Weiner To: Mel Gorman Cc: linux-mm@kvack.org, Kaiyang Zhao , Vlastimil Babka , David Rientjes , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [RFC PATCH 25/26] mm: page_alloc: disallow fallbacks when 2M defrag is enabled Message-ID: <20230421152448.GD320347@cmpxchg.org> References: <20230418191313.268131-1-hannes@cmpxchg.org> <20230418191313.268131-26-hannes@cmpxchg.org> <20230421145657.fnpjqkuyquy3z24t@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230421145657.fnpjqkuyquy3z24t@techsingularity.net> X-Rspam-User: X-Rspamd-Queue-Id: 39D5180009 X-Rspamd-Server: rspam01 X-Stat-Signature: buia7pokt6cuwjrn5othoc193nx94z15 X-HE-Tag: 1682090690-63506 X-HE-Meta: U2FsdGVkX199bUnMHUAa8xFfZ6pTJSiV1g9JCEdbNhNYz4DQpkzT35DliicHY3kWL0CyBb2t+yyjSJhbX7fZoBerSKGgA+76IrlIumbnPT5Di4mDkjA6+PGsC5Fj3yUeB7pTbLtKXQXkn7n/0l1sVPEAWwFbDiXUz/gj+6bQj/wcIaA6tETt76ZkpO/2e0QkMEXMNFIam5qa1Szn8JZo0D/A3irWZD+M2Oe8ujZsFx+1W20RH9NWHF92fU64v6sKScSLcfesiiOJLnQXocLp2j3BMMg+Kz9x8ei1f9GV6EJnjOI+cloF0HmznI9O8Jfx6LD0RQjbE12lD+5viVGknloNWblNtVXSxUwvMS3cafvxni4IX/ySOa2NC0QCqhlV4Tfukuxk7JWgxu20OE+0j9t2bsSGXCdSRZPOU6eTlUEzzLbXVFB0yA0XAQ++r1dHlG5V2Tjin5CSnDqDLoR//Erz1AaManU8fMjUOO1tHRgvJFqsbPf3rOuvcWJJYKMuhp9NoPkTFDr2bQsBm0e2S56Y4kpvdu9yXjcoyRhVv9MG1h4oSI812zAQvv9eK7TY1KLfrMrAkaBnYQnDYnOk+pTxuTYA6WQQkBShNnU07BK0hZrN9upZv4/fgUvl/UvZwpED5eOkBpdWT75EQbutQKhlZVpZzbmjQtuFc4icywy+fSQUnaUh5QVOfRLuZs4XYmVUjBObSQ0gDBgzg9/sVJ+NMFUQoqCbkhl28CfY4wYjLkR5zmmhiRXrvItQLUuQYM1G2k1xW6f7XJT02Y7hvw2ahrqXwYYuOAXKC9K9daSmQRs6q7gYNZXjPXRHnnobNwa8rc7zRGsR72KLXOshCGi1tlW1pjV7brXk+S2+XiN3iBP1Y63Hy19nVTG64zYm/aO08Bo4s4QApJTJIcnQudux7OmxGu+tb3OAnJDtxWKaSpMf4M1+Y+995bfQGy6eNuVnSKfXZajI2DwasVB jLLL4NJe D6Mbtq+juN7IPZKFGOCp1FtkOCsovm6BO4RXOE2pe49bu2WRWRs6J9lPlMURn6uQzlqIUBHZasuvGssHNxF2NNQe0lrDhpmG2b5XOrxWveTnbufa/QEAzajNOEXsgZiANRjQDatZDTTfDW2kztTdWkyPixqKsE6A9LFNxIb9VIkJ+on5UANjW788Ju07WWM4zupGx0oK1ssKKijDLw4AlbqxzE16rCQgBOBd09JDJ6lGmtjzOA3rZkCIgJFsIN7b4xWvtb5euxH1GEpY+QwdYj50/w4rgwYfjfF7SbOFAW0PBz414FEWnM1j7l3FhgxTq5d85ofXHZlWPqDtocKsUgesCOxWCspRszZJU2zl8IAT7kKTArtm8g/B+Bu/Rc2ebFy1gnhIzcmA2/Cv5cDxFbGa3LIY72w3RFvWI7D76v9m1M07fkCItyOZ8B8sbyDJGi/Qwvv5AM8RU8d/gWnuoMNQ86V1iG0kNAAoLczWXUAiXrTB943EU2CMRcoHpJOmeQSIsSagQ/CmOAmDtar/jbY6PYw== 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, Apr 21, 2023 at 03:56:57PM +0100, Mel Gorman wrote: > On Tue, Apr 18, 2023 at 03:13:12PM -0400, Johannes Weiner wrote: > > Fallbacks are already unlikely due to watermarks being enforced > > against MIGRATE_FREE blocks. Eliminate them altogether. This allows > > compaction to look exclusively at movable blocks, reducing the number > > of pageblocks it needs to scan on an ongoing basis. > > > > Signed-off-by: Johannes Weiner > > Conceptually this could be fun if a GFP_NOFS allocation cannot migrate > enough memory to free one pageblock and there are no pageblocks > available of the correct migratetype. Fallbacks might be unlikely but > never being able to fallback is a livelock risk, no? The reserves below the watermarks are maintained in neutral MIGRATE_FREE blocks. So just like today, critical/limited allocation contexts are ensured forward progress as long as there are reserves. An argument could be made that because smaller orders type-claim the entire neutral block on allocation now, the reserves can deplete faster than they do today given comparable watermarks. I haven't run into this issue during testing that would have me raise the reserves by a factor of NR_MIGRATETYPES. But something to keep an eye out for.