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 C3CD0E77183 for ; Wed, 18 Dec 2024 03:29:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17B6F6B0088; Tue, 17 Dec 2024 22:29:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12C086B0089; Tue, 17 Dec 2024 22:29:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 019F86B008A; Tue, 17 Dec 2024 22:29:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D95616B0088 for ; Tue, 17 Dec 2024 22:29:45 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8CA1CAF520 for ; Wed, 18 Dec 2024 03:29:45 +0000 (UTC) X-FDA: 82906649112.25.998CCB6 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf30.hostedemail.com (Postfix) with ESMTP id 8F6BE8000C for ; Wed, 18 Dec 2024 03:28:43 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=A0OjSbDG; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734492554; a=rsa-sha256; cv=none; b=WpmIutA98s85dZFLZqK7fuSeFWlQ1GZcAgt+KYLftnQORM7oz3vyjlnIXSzj2QyTBicf84 Osyp0bpkSVM5q/XilSPwLZmp0HEdfRufrAxGvmvjbXE0MgSFi8mJfYEG1mZzHIjiBPcOiO l91dPj6HtW97cv288xsg10613c17x4g= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=A0OjSbDG; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734492554; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8sFCiqrsFhJd77PzvN7YCxoQJN0smUXicUyoUHy76rU=; b=D4+JsdtPciQVPtuyy2qpp6mwX+zxymTsH2n+L5n2mw6JPaftwp8rsO05yTzOto+YaUY7Bz ftfXgWtQbNG6uzupszLMImyX7wnuje4lG+zdEdqUFfhS0e+4LprLsuUx8owQBm87VNNZm1 Lj3UpUvu+JXJFP0wighymenQXnrj67Q= Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-7b68e73188cso707003585a.0 for ; Tue, 17 Dec 2024 19:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1734492582; x=1735097382; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=8sFCiqrsFhJd77PzvN7YCxoQJN0smUXicUyoUHy76rU=; b=A0OjSbDGKEuR3V2nHEniesDmrQ5HiXZkO7Frcr12EeG5aC7EbYCVXDjloegD4a3XFi 71/D3o+2gGdZRaxJKxhdQN2NcdZsBCTX+ZnuFp+u073PY6tUNL00KFTPHyHPEw1dM1pv iB51C6yfLnpya/hKHEnOX6pzkkK5dfXQh3N4uXejrUWnlSqerSZA5ZcHndNqyQxp12+t tzeyeUQZA+QVrmzKezTuakqrfkvtn8EDX7upKD/2GUkpYq0DUZG2om7aHVCthN0yWETZ A0A96QzlAgT0ggjQheG1jE2nbr2bUgwBw0CovL/HMAZbJgmDy5jcYVFI16iDxaZrvLDU mniw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734492582; x=1735097382; h=in-reply-to:content-transfer-encoding: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=8sFCiqrsFhJd77PzvN7YCxoQJN0smUXicUyoUHy76rU=; b=bypUlQd+ojq3uA6BoE8uLgaZQzINJfBxTQVI6w4pQE5J1g1srUGnwHRWiQIhRcnTKq 955LYY4hyT2262IeRqNuoqDDGfTh1vRKVfHnduqJNxPlJQOd+yo/Z6Pf8B8STfCu9K4b tNUOANWJ1GWmkyXKszZG9PPIMe8h0gbc8v/8krolh9Oye6Lqm0zglVdwQwrGm9aea6+i eWPPDcG3pKZEz0hQgdVhKWMue2jXzqpkdffSmypKnhBly0oHyFhLyJZUfgdl+AXPap0k TGZAH+93unav4B+VLGceRwOdgYdFfOToBEkw+tfw/rI8B9394aSex/C7azC74v68t4Gg kr5A== X-Forwarded-Encrypted: i=1; AJvYcCWts12ZJH/nKeH78aw5q2+INC4DDaa9Ik/ThHAVmDaSNaWhS0dSG/8RBfe39659inOzeP4X/LshWw==@kvack.org X-Gm-Message-State: AOJu0YypMz9uWrkCLaQzyXcGuHVmzO13/nx8Tn4uCz7vZjR3mp8+zkbb Gtp354T3+ptXymLhsAPo/vq2fZmbSJndWms3o6K22W4SLBPfqm9IGyM1Lj/nR9U= X-Gm-Gg: ASbGnctvnOBZc52Tmu5XjJOXXPYJearsWhMhrDFhHlZ3j68YrN0hV/BzsS/yQLb8BWj 7YCbjLjyGKwo4tvhEdfvCxy6lcmaa5pUqJjwOLQm6RTns0NvGCzl3BJJB7u4rWjIPzyxb1Ts0CM uUCjpltPLuebqa3uVA5IE3CPFy3WOr0V6zsR7To+bzicIEP/6kmcpTarXeAHbgqHcCtyooCAyA7 t+aswAfMMpkPsDb6mVn3WlZD4zO7Z6PBPTSRxQATZob0QaYJjNogLM= X-Google-Smtp-Source: AGHT+IFeMqWNmRUmKohC9SEkTzUoRaAT605wLZjWlCNLlwn/7mHLCzbu8bekeFz0ggKtPGUhsoEIYA== X-Received: by 2002:a05:620a:4608:b0:7b6:77f3:b1b0 with SMTP id af79cd13be357-7b86375aa84mr228883485a.24.1734492582351; Tue, 17 Dec 2024 19:29:42 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b7047f3568sm380762285a.64.2024.12.17.19.29.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 19:29:40 -0800 (PST) Date: Tue, 17 Dec 2024 22:29:36 -0500 From: Johannes Weiner To: Ge Yang Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, vbabka@suse.cz, liuzixing@hygon.cn Subject: Re: [PATCH V7] mm, compaction: don't use ALLOC_CMA for unmovable allocations Message-ID: <20241218032936.GB37530@cmpxchg.org> References: <1734436004-1212-1-git-send-email-yangge1116@126.com> <20241217155551.GA37530@cmpxchg.org> <93cf1aee-70df-426f-a3c0-1db8068bd59a@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93cf1aee-70df-426f-a3c0-1db8068bd59a@126.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8F6BE8000C X-Stat-Signature: rk3mwnqghp3wkdorhfwnk3iaqkesy7sg X-Rspam-User: X-HE-Tag: 1734492523-502779 X-HE-Meta: U2FsdGVkX1/bGWnil2+xt8G+TW5KDLf9bzV5xCYxZXp5CwY3fsrm5EMFKnAArSVtB/uamqDRXicNfqRUu2oX/iNlALL7jWstCOlt5yK/Xn+oE/DBqwbpG9KRlJsICvxq8Fl97JDdNj1YpCgWtXmW1D+tlseRsW6PkWzuM1CqQuOV/Hacu0XtEwCYBdvOliztekWxfXXbOOBFizG6ShytRpYgeUypD44KznHDDnqH3X84Up+ZjLi7uJrMEAOSlbgvd4TAidLd6SXdjcy48/kh0tkVYrGNq1JTSMxxXlstrrsV39ZkzU5NuILfh+vc31Ee1sIOTRH6O+GtJ6RbpxUQLItb5tN0NxgodYx4cC5vu/AMfGgYG6F4baAq1rGkiP32xMiHFuA9wg7fO9vo2ZlSc/9po6IkDVpLjFC6P2SFEnV3o9Hosqd5P6pDaLufjdJ/PuYpzZBZnhiRnaq0dPI31VlEaMa9tDsZJsWJoOMx/rteizJFbAYRMV1kEF84SAbwZyuwOQb1vryWMNfC3kXSkkEmz83qWJcPIOP6s5/Wlg5WMw0iLZ5ohz8QUHt90kUT5krw9un3z+/yxEN4RJGoaEZoOGIBhRJTPTQFR5rMGRRZaf+ClDHDEwkBImmffkwGP5mfwNKsRdiUXq1n4I7EtQZA/kPScDqMTkDceV52wgnvmnLVaIh6CQRdwOKfu/6q1w0nzSKZIBFB3hI5nknwMV2zVM8/yuTQx8E3qSH2feWmDwVWfZELxC/Ly1n+r87iiW5xX3Ota4nHTbcgsvKfkj3Nn9QzUoCPkXHWMeqoDLksUx1XIoU4hd7DqbUPxc2o8dyw0bi0TAfUQAu0RU5i2gO/b1u20wzN40rnQSwCLnLd960/dDFIm4awFywGvaE5XZDv48TKLfyiEc3O0yLAJ/BRh5/sF4meUFPOuE7KQFvFiO/mBlUJsRkxDsqlOth2vqZnscGLpYuD4LixoZp Ey60ZPhp 00CsOU4eijFkFlejuGc/ZSjFd+bw5ZE53IemOVkbAGrWO5AQi3Ktb7E5MxXhR2QhH82DLaT99jYyrTs8BBUlc3tbqf+cT4EmbXysuz/I5+5ubl4Sm3jXMGqbCDuFJfHiMBFTTbC2gu4tl7KqQwUBzI5kKuyLVgECYvUGg0tIGACFcijQsz4EPyqPcMf8wYC5oMymnWPoVdymfsyfmqfql4N5rElZdnq9PB9GEjt+Hgewl1T11yXtL3XyVru9ALJ7zypyP5mLeieUMMw9KJ27kAMBATUVWQ2kfVJfU3F6jNcqqpjjd371fwJxhJqu+m3VRbS9UUpHLf5gF9XHpC5q+xpB2NH1sL0TnOyMZwe808td/UjRlbQv6tzcEyKD3elCY2iWOTHumWobf9ULW73Mj7ukx102LqK8NYT6k56jrWRkRnDacGtcFPVK1Uu/jS8jbDx8wEBntUWQRvgiprPCXf15eGkXl2UpaHH51Xayj4P9UXw22mENYxfvH93W8yHV55Zl73L7FVVGINz82GG/wxUx1LkG2g9Y+PDR3UN7Q5sj1UfR0dTaTC+JK+PQ7R1UmQhVdroferKG5VFVICCI3XeDLyA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.281670, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Dec 18, 2024 at 10:15:06AM +0800, Ge Yang wrote: > > > 在 2024/12/17 23:55, Johannes Weiner 写道: > > Hello Yangge, > > > > On Tue, Dec 17, 2024 at 07:46:44PM +0800, yangge1116@126.com wrote: > >> From: yangge > >> > >> Since commit 984fdba6a32e ("mm, compaction: use proper alloc_flags > >> in __compaction_suitable()") allow compaction to proceed when free > >> pages required for compaction reside in the CMA pageblocks, it's > >> possible that __compaction_suitable() always returns true, and in > >> some cases, it's not acceptable. > >> > >> There are 4 NUMA nodes on my machine, and each NUMA node has 32GB > >> of memory. I have configured 16GB of CMA memory on each NUMA node, > >> and starting a 32GB virtual machine with device passthrough is > >> extremely slow, taking almost an hour. > >> > >> During the start-up of the virtual machine, it will call > >> pin_user_pages_remote(..., FOLL_LONGTERM, ...) to allocate memory. > >> Long term GUP cannot allocate memory from CMA area, so a maximum > >> of 16 GB of no-CMA memory on a NUMA node can be used as virtual > >> machine memory. Since there is 16G of free CMA memory on the NUMA > >> node, watermark for order-0 always be met for compaction, so > >> __compaction_suitable() always returns true, even if the node is > >> unable to allocate non-CMA memory for the virtual machine. > >> > >> For costly allocations, because __compaction_suitable() always > >> returns true, __alloc_pages_slowpath() can't exit at the appropriate > >> place, resulting in excessively long virtual machine startup times. > >> Call trace: > >> __alloc_pages_slowpath > >> if (compact_result == COMPACT_SKIPPED || > >> compact_result == COMPACT_DEFERRED) > >> goto nopage; // should exit __alloc_pages_slowpath() from here > >> > >> Other unmovable alloctions, like dma_buf, which can be large in a > >> Linux system, are also unable to allocate memory from CMA, and these > >> allocations suffer from the same problems described above. In order > >> to quickly fall back to remote node, we should remove ALLOC_CMA both > >> in __compaction_suitable() and __isolate_free_page() for unmovable > >> alloctions. After this fix, starting a 32GB virtual machine with > >> device passthrough takes only a few seconds. > > > > The symptom is obviously bad, but I don't understand this fix. > > > > The reason we do ALLOC_CMA is that, even for unmovable allocations, > > you can create space in non-CMA space by moving migratable pages over > > to CMA space. This is not a property we want to lose. But I also don't > > see how it would interfere with your scenario. > > The __alloc_pages_slowpath() function was originally intended to exit at > place 1, but due to __compaction_suitable() always returning true, it > results in __alloc_pages_slowpath() exiting at place 2 instead. This > ultimately leads to a significantly longer execution time for > __alloc_pages_slowpath(). > > Call trace: > __alloc_pages_slowpath > if (compact_result == COMPACT_SKIPPED || > compact_result == COMPACT_DEFERRED) > goto nopage; // place 1 > __alloc_pages_direct_reclaim() // Reclaim is very expensive > __alloc_pages_direct_compact() > if (gfp_mask & __GFP_NORETRY) > goto nopage; // place 2 > > Every time memory allocation goes through the above slower process, it > ultimately leads to significantly longer virtual machine startup times. I still don't follow. Why do you want the allocation to fail? The changelog says this is in order to fall back quickly to other nodes. But there is a full node walk in get_page_from_freelist() before the allocator even engages reclaim. There is something missing from the story still. But regardless - surely you can see that we can't make the allocator generally weaker on large requests just because they happen to be optional in your specific case? > > There is the compaction_suitable() check in should_compact_retry(), > > but that only applies when COMPACT_SKIPPED. IOW, it should only happen > > when compaction_suitable() just now returned false. IOW, a race > > condition. Which is why it's also not subject to limited retries. > > > > What's the exact condition that traps the allocator inside the loop? > The should_compact_retry() function was not executed, and the slow here > was mainly due to the execution of __alloc_pages_direct_reclaim(). Ok.