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 3217FCD11C2 for ; Sun, 7 Apr 2024 06:58:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEA076B0082; Sun, 7 Apr 2024 02:58:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9A476B0087; Sun, 7 Apr 2024 02:58:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 960D86B0089; Sun, 7 Apr 2024 02:58:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7834C6B0082 for ; Sun, 7 Apr 2024 02:58:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3E8161A0868 for ; Sun, 7 Apr 2024 06:58:20 +0000 (UTC) X-FDA: 81981831960.17.75DA5AC Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) by imf25.hostedemail.com (Postfix) with ESMTP id E62B8A0004 for ; Sun, 7 Apr 2024 06:58:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="Cg/VJ8Ee"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712473098; 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=keZgjnQ9O+2hNdJMQ6VR91QK3KYWM4wdrpBYXw8no5M=; b=f1+ub3UvtC92yKrYcQdYmY4lqRJA/qLoqzTq1Zu+CXdQIk2aBHnfQKJag6fMV/54G+AQhM RCCUbEhsSA53NtgnaHPbg6dhHZ6+YQNnphL9vyVqwi9MD+8/w5EpmNneArVx8bYssrmL+d fWJ2yLKJB1EFJNR82Yu2Oqz3Qz8Ix30= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="Cg/VJ8Ee"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712473098; a=rsa-sha256; cv=none; b=6yd4aasZRmSuTn59WfR5kcbMOQ+OA7AC9NoZQb8ygkrDyhaVByZ67YwHh9OWY3sBEkSeBd H7TerEr8+IvV+xJga/0teUA81m5hkxfjZsgdP3pGC/VjjJoF+is1gMjpnsk2dsJKsn1PbN Vu6JSpKBEIAV8NikN9G9iStGZ7KvrfM= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1712473093; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=keZgjnQ9O+2hNdJMQ6VR91QK3KYWM4wdrpBYXw8no5M=; b=Cg/VJ8Ee0tIMlS+yg/vXdUolOmRM/n6olTELs1EjRM/6MRccgUXhHOOFAGv5mhjQzP6jfdAvBSFvUcZ6Vz7kvUQN4wkd7a1gjLm0VUY6HTOXP+hEWTR4qC5uhq1wiAcByYl8wMtldIbQfv3SCA7Eri1haDkLfZXJhxTQPj5xYxE= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R681e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045192;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0W4.dlUx_1712473012; Received: from 30.97.56.66(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W4.dlUx_1712473012) by smtp.aliyun-inc.com; Sun, 07 Apr 2024 14:58:12 +0800 Message-ID: Date: Sun, 7 Apr 2024 14:58:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/10] mm: page_alloc: fix freelist movement during block conversion To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Zi Yan , "Huang, Ying" , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240320180429.678181-1-hannes@cmpxchg.org> <20240320180429.678181-7-hannes@cmpxchg.org> <20240405165632.GA870124@cmpxchg.org> From: Baolin Wang In-Reply-To: <20240405165632.GA870124@cmpxchg.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E62B8A0004 X-Stat-Signature: p4o8e4syf7hzkzyxccx6nd13bpb8cihr X-Rspam-User: X-HE-Tag: 1712473096-856849 X-HE-Meta: U2FsdGVkX19XNshAFxn5nmToE4/+ezoEYkgootfbATHObmRq2UHEeJYL8jb7dlT8QvlTumEINKVn/KFDUfU1Xuxy6ZwSdJzBXKKOP1nhwit0shJ474mjRJZyWnXMHHQS1grWebAZVHupjqStIh6Ymse+QUqqyLMs2QQYnDG2YNjeBExGRT2od+psMBI25NLgOtdNc5pRx13KxHvFWHoyY+UZknVR/hatmmF/I5wcJk/Z5hTJogBFD2B4NucWgOOHblPLdSxTEXVT9fx8aawEBW8p485O8Tku1tVw+fn+TWb852/f6Fa4oOoWuCTjaabHZ3pgT414AtZ7P5O+9IDFDdt/9dXtnD6SbswnZkVuXTgCiHNl2TQbZeVn/YD3v/OTsDsBTSTbI5Q6EaJ/07LaYDHg2U8gZxqrTM2YG7syJ2cc1BYc6cEwrWlXyz2Ie8l0us10Ngo2ksbRLRhK2x4hjNxlNtkVZmAPR6z02as/45L/izor/a/aIGjhXJcVRFX9BKthxivs6CGZ2Rz974xOYhS3mCCpOtaHz+/3kljuGB9eY9oIwR2MUtFZSi8IChYtN/cD9fKmI34hBGKbrEhVCmQt5J3T8o02HOrGkeI59V/0ztlDKAf6n+P6nYtKwzyajfJAkdZzU5/cqCab+fVNI14+FqOut52VKaeb3//An1xJISs4nQRAFawQKvA14z+CKGP8cQuZE7UeHqJ+Es0/WtTXl84ye2QyQzZJR9ibzeGAJRIw8zt6Q1PF7AZ8ZnAdszQ3iErIQ3bL/XA13XEuUgt/B2Y02ZJCjfCf0VCre8f59nEjjyRX20MZXr0e6PNkhhbKSIIR0vXZ8Qde255rHda0b2VsOgaqxZan19iAI3VNcy9VqR12/564VgOv4JHhQqfTU3M9rpcoTl9NDoTzaM2jFpPtdhL9JWp6ngwUKeBmPU5q0GqhAlG3WuJcqKF6dPcdJue6kaLWy3hO4sn CyeL9EPu Kf0grEHM/B680xe10SE1hHne3IZ5g2ZK9z1oSdl3yeC04aAnX/C4/yfIK+EIWnrRt41lz8HhxduqLi5zNhSwh3Cub9PhrSphS3VlAK95qywoVMFpguMiGvKWQ9YF+Uq49sNqPjW7owOPG+dM8Iynw/WCGpaVOM9Azq6Ff0FQQSseYJ7QEVQIp87eWYR07Dlcz4UkvTqdyG/h/PrsvBGhLX+/mUflhjCeX0B31bsk0QV1Ny1Kan25bnXvd1K9SMco3eSf9ZBJzXsjbI6inknVdiGHGIv6c5REYl3tVjMyiSmn5VURM/n15dWfNMsspSNOXMqVLWV+ZpY7HPrqX5YPC52fX7y05yIfvjcopmjq0D6gL+s4hS/a9RV/cSw== 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: List-Subscribe: List-Unsubscribe: On 2024/4/6 00:56, Johannes Weiner wrote: > Hi Baolin, > > On Fri, Apr 05, 2024 at 08:11:47PM +0800, Baolin Wang wrote: >> On 2024/3/21 02:02, Johannes Weiner wrote: >>> @@ -2127,15 +2165,14 @@ __rmqueue(struct zone *zone, unsigned int order, int migratetype, >>> return page; >>> } >>> } >>> -retry: >>> + >>> page = __rmqueue_smallest(zone, order, migratetype); >>> if (unlikely(!page)) { >>> if (alloc_flags & ALLOC_CMA) >>> page = __rmqueue_cma_fallback(zone, order); >>> - >>> - if (!page && __rmqueue_fallback(zone, order, migratetype, >>> - alloc_flags)) >>> - goto retry; >>> + else >>> + page = __rmqueue_fallback(zone, order, migratetype, >>> + alloc_flags); >> >> (Sorry for chim in late.) >> >> I have some doubts about the changes here. The original code logic was >> that if the 'migratetype' type allocation is failed, it would first try >> CMA page allocation and then attempt to fallback to other migratetype >> allocations. Now it has been changed so that if CMA allocation fails, it >> will directly return. This change has caused a regression when I running >> the thpcompact benchmark, resulting in a significant reduction in the >> percentage of THPs like below: >> >> thpcompact Percentage Faults Huge >> K6.9-rc2 K6.9-rc2 + this patch >> Percentage huge-1 78.18 ( 0.00%) 42.49 ( -45.65%) >> Percentage huge-3 86.70 ( 0.00%) 35.13 ( -59.49%) >> Percentage huge-5 90.26 ( 0.00%) 52.35 ( -42.00%) >> Percentage huge-7 92.34 ( 0.00%) 31.84 ( -65.52%) >> Percentage huge-12 91.18 ( 0.00%) 45.85 ( -49.72%) >> Percentage huge-18 89.00 ( 0.00%) 29.18 ( -67.22%) >> Percentage huge-24 90.52 ( 0.00%) 46.68 ( -48.43%) >> Percentage huge-30 94.44 ( 0.00%) 38.35 ( -59.39%) >> Percentage huge-32 93.09 ( 0.00%) 39.37 ( -57.70%) > > Ouch, sorry about that! I changed that specific part around later > during development and didn't retest with CMA. I'll be sure to > re-enable it again in my config. > >> After making the following modifications, the regression is gone. >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index ce67dc6777fa..a7cfe65e45c1 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -2139,7 +2139,8 @@ __rmqueue(struct zone *zone, unsigned int order, >> int migratetype, >> if (unlikely(!page)) { >> if (alloc_flags & ALLOC_CMA) >> page = __rmqueue_cma_fallback(zone, order); >> - else >> + >> + if (!page) >> page = __rmqueue_fallback(zone, order, migratetype, >> alloc_flags); >> } >> >> But I am not sure your original change is intentional? IIUC, we still >> need try fallbacking even though CMA allocation is failed, please >> correct me if I misunderstand your code. Thanks. > > No, this was accidental. I missed that CMA dependency when changing > things around for the new return type of __rmqueue_fallback(). Your > fix is good: just because the request qualifies for CMA doesn't mean > it will succeed from that region. We need the fallback for those. OK. Thanks for the clarification. > Andrew, could you please pick up Baolin's change for this patch? > > [baolin.wang@linux.alibaba.com: fix allocation failures with CONFIG_CMA] > > Thanks for debugging this and the fix, Baolin. My pleasure.