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 D71ADC77B61 for ; Tue, 25 Apr 2023 15:40:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 745806B0071; Tue, 25 Apr 2023 11:40:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F5CD6B0072; Tue, 25 Apr 2023 11:40:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BD626B007B; Tue, 25 Apr 2023 11:40:31 -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 4C7076B0071 for ; Tue, 25 Apr 2023 11:40:31 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1C6111601A5 for ; Tue, 25 Apr 2023 15:40:31 +0000 (UTC) X-FDA: 80720325462.11.1D19BA5 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf11.hostedemail.com (Postfix) with ESMTP id 2B64740029 for ; Tue, 25 Apr 2023 15:40:27 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2qVMPflr; spf=pass (imf11.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.52 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=1682437228; 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=Sz41xh9WX8qoOdIKJmQdrlGwHLiYgLl85XIU3W+xHVw=; b=a9dH/8AfIDjCwnN/EQlpFOL8qr+utLNF2/0gzwHdf5H+Z4B+KMcufw8uyCT8w6k/3rTFCi XZ4ltyi2nFtF6qwpoIDWHphvngrClwVBn7awOmcnMVrU9Y9PLy9nCv2sABrrriVHtTQW4v EGmif/n6T5FB/lxDtF+Rbx6aaVQnitc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682437228; a=rsa-sha256; cv=none; b=u5xZ+amXi0Pssr8IyIksBlpPMs14WkBWhcKRYwYehPZDkmC9CqCW3npLXsfbB0jrzacvX8 0CRQ/mX1NWe+YI7UzTvo325tV+78nJvgOV3HlYVUA87SOBHYMx0KF1AUELtRBzJiQkpRkZ f+oS72e8gyeisdVtxfOxXgByH11RW8g= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2qVMPflr; spf=pass (imf11.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-5ef6b757a60so24798626d6.2 for ; Tue, 25 Apr 2023 08:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1682437227; x=1685029227; 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=Sz41xh9WX8qoOdIKJmQdrlGwHLiYgLl85XIU3W+xHVw=; b=2qVMPflrw0T2LPyFNNegzJLB7Ix+X+y/YwEnVHEFh68utKtzCPTrxVkh+KGE1XsP7p 423MfaUjxVUhxljQdhfCN7b/6jyUl8aszB9beZFyPkhWwe0lfNN+MEl9zMAGbG35/N78 97KF8xEr0oha4QiyEkxzcqXkayiVjDbtLubf8GPSdjPeLpvNyJFgP8gz16yrOIAURHfM VB58Eg8hAc73o/MEDV5uoSF9TCkzgSLVbYuDZyVMHsnDoDvDrDZWh4dvWLInKfTbfZBl b/1GR+dzzWtsU51sZ7MlhPDXZxCJGFs2rntlOKwNLysXWkj72t53CensQdT3boyhoKoX eBMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682437227; x=1685029227; 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=Sz41xh9WX8qoOdIKJmQdrlGwHLiYgLl85XIU3W+xHVw=; b=kTsfX3RfFeHzp7EPPtEbtM6wFfOMNakr1S/Anv35sJQrFXWmxRzPqAGCzqdQ/mLF6L SIIzQIW4fxaavhfBY8Y63bJwQyh9Cqw082IaKd/OUVGFn/fierxsm6F3ZGEhRYWvueSf 43INDhbNyFtXD5TiCWEmNXHqYVMWvJnm6I2K+tAqUez1l9NTn+2/TKQJ9vJVCFISpvBf tcbwaz+fbvbRBUKYXczxX5uENtVH+FW3Hiue7XeZ1Le+gjGUgDhvq9o4za+0nRARTfWE KBi9aDAcVoZ7KE2hsIIat2yfx59MtD80xd1d7K5uWoRJtIiEobydsnj91MHFPAJbqfem 3/qg== X-Gm-Message-State: AAQBX9ekIEbIhgeIj5AW7kF0TRRbrHalTrR/Li1Mj2PsWZk9Xh8IUJMb g7RsYn5LH5wdPtTUJ3UoqfIC2g== X-Google-Smtp-Source: AKy350ZuTU2+gfPuqlAYRQHG0DYc6Hd46OaxYvfknDpwSYIfN8LpMy3/mSs14uvFnKehLaoG5YSxZQ== X-Received: by 2002:a05:6214:242e:b0:5f1:6bee:f58e with SMTP id gy14-20020a056214242e00b005f16beef58emr32598066qvb.35.1682437227122; Tue, 25 Apr 2023 08:40:27 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:9fc5]) by smtp.gmail.com with ESMTPSA id k14-20020a0cf58e000000b005eac706d223sm4173628qvm.124.2023.04.25.08.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Apr 2023 08:40:26 -0700 (PDT) Date: Tue, 25 Apr 2023 11:40:26 -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 10/26] mm: page_alloc: allow compaction capturing from larger blocks Message-ID: <20230425154026.GC17132@cmpxchg.org> References: <20230418191313.268131-1-hannes@cmpxchg.org> <20230418191313.268131-11-hannes@cmpxchg.org> <20230421141447.2cw5cfwibb7jxf6n@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230421141447.2cw5cfwibb7jxf6n@techsingularity.net> X-Rspam-User: X-Rspamd-Queue-Id: 2B64740029 X-Rspamd-Server: rspam09 X-Stat-Signature: yfekxy5p5gnyw1hp7tmnw7gygepumyep X-HE-Tag: 1682437227-714627 X-HE-Meta: U2FsdGVkX18zOOPrFHb9G84W0MvcEkULXcF0x5UOQXXRJC5MtevnchmSAkELuuIHPE4mhPHIwDFBJefnaMQ6y8yFzS9MWC6Ls6CSE15XQRAGszFnNZhd7mpheKT/BOJcakxYq3fh4fiBAaB+ItGBVh6A1lC1xXv9RUUM0/iqQbuMnWHBi8vvVh+qUGSmXmns9oiA+3JezSl+307tEPanLp8N5cpFJRFwO+U4UckIkEl+QOn17R6ar0B1DgTe9PDmPaGV5QW16HB4wjL8g5Y9LnSQkintm9nl36L6MD0RmKxIhbHdGfhoPNxfoq2FePmWzA01iW8WultDM6uW2sWND4ey8+joNH8Uhv1MzUhQlY+PSQMzWyNt329lE92agrCCEJZ1QluLUQCSl1CQ4Lbl12SVhP7wXpE6RquA73L10C1CocyBjHgZ11Fd0K52tEnGRuJIi/HarilJ1n1abfRTvBWRXoNDrbssY1CNd9RqL6fMHBkfGIslLFnke/oV2/0eJ6LPaS/cPWbVUhtn/+2aMMPBdqdcntex+NB3jppbQm0u1Z1cr7z3Zptfg536+vdY4oA80646oP4B5RLDzqwJn55JTUusgOS27X+IV0A5eT6Rbdn+P5RcS/BENscXx8HUfFHayoKvEBgK80q3WOaTXuzeqcWpoCDm/AKFTgcKpDHTuP/K34fNSmuA9M2R4foFAYRAkJuCXizUQk91kRkPtZ7ykXMIp0+KUD/Ih/qiGmAz/nlJbO1nSPOuQ9ldZpl4O2XaCW1TFpGoQaberpTKpAx7T2rnoz7WAHizgXK2ohEmBfqDSbEKMnoewgsRZw/OeEDmt6Mk6CAV9zGbpivY8uegbuQeBb1sX4KpzhV6qet0nTeOR0Ve1V8YJ2yiaZNTtEuj4tpWPWAS6jo8Z825tXznCNOk9xUT3/OCpFn/5Cw9KvbUwQfcQPQ/HJe0uE7PksQ0qibaZ5yYuzm8U8l f3HlxbeY mAWaegr6OnGOadjp1X58xk6gkd310egBzVmN5uTYG4Dg04vKyzPNx2EbA4BcZko7jOh2cfYegNFiLuzW2tB649K/yv5XjCPFyA0YaVrS5dLxZP5IgoLDEmoATSvGssv4OpcAv4hXwWLavmXS32DAApflJZNRWQCR2gmfFkOAUzTmfiScWLerGCbFQ7+vAPnPDay0pGkmr3H5P+kYi32GJdeAMsmBJf1Zjm7fkgJd5xUAMeP1u7InKVJe/FLPDUMAQZRZHxMDU7HYMEiWSItS0M/D+Jvs8OHeTBaeYKgIXo0Oa7jPm15rb1qpVYkYqinK9KoP/xfPj+jyFf4KL4rDQlw4Xh5MYnGQqXLQesBHy2FkiMrOJ0fEhOK2yvpXPV+zSisvL/lHTjH09vW0Vqd1uOS3E0N6kdGgxVGxkCl9l2HXQQsT5K4TLU+KiCBX2rp+E+d19cMulnZjxuOjobCDS5vQUm2vIqv780eHv8/8+2RWGZ0ZeiYRs8AVgYxuHJR4nzk6meL0guzArti6wBEjxdP956Q== 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:14:47PM +0100, Mel Gorman wrote: > On Tue, Apr 18, 2023 at 03:12:57PM -0400, Johannes Weiner wrote: > > Currently, capturing only works on matching orders and matching > > migratetypes. However, if capturing is initially skipped on the > > migratetype, it's possible that merging continues up to a full > > pageblock, in which case the migratetype is up for grabs again. > > > > Allow capturing to grab smaller chunks from claimed pageblocks, and > > expand the remainder of the block back onto the freelists. > > > > Signed-off-by: Johannes Weiner > > No objections other than we're still in the preparation phase and the > series needs to be split. Out of curiousity, how often does this actually > trigger in practice? I ask because superficially, I would expect capture to > happen while pages are being merged and I'm not sure how much this actually > helps. If anything the anomaly would be merging !MOVABLE types, capturing > one pageblock and leaving the adjacent block eligible for splitting as > UNMOVABLE/RECLAIMABLE which is not necessarily desirable. Looking at this patch independently, once merging continues to the full block, a fallback would be allowed to claim it anyway (can_steal_fallback() returns true). I don't quite see a downside letting capture apply in this case. The plus is of course avoiding the indirection through the freelist which risks an opportunist request of a smaller order fragmenting the block and wasting the contiguity work. In the context of the full series, this becomes even more important. Once watermarks are required to be met in MIGRATE_FREE blocks, and reclaim/compaction recycle full blocks, merging up to pageblock_order happens all the time - and needs to happen for allocations to succeed. This applies to all types of direct reclaim: unmovable request freeing reclaimable/movable blocks, reclaimable freeing movable blocks, movable freeing reclaimable blocks. I see your point about smaller orders now always ending the merge at the pageblock, even when there could be additional merging opportunities beyond. However, I'm not sure these accidental larger merges beyond what's needed to fulfill the request at hand are a preferable aspect over reclaimer fairness, and thus ultimately the reliability of orders up to the pageblock size. I'll try to get some numbers for this patch independently, though. This should manifest in p99 allocation latencies and near-OOM behavior. Is there anything else you'd want me to look for? Thanks!