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 3CAC0D637D9 for ; Thu, 14 Nov 2024 02:58:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33F926B0085; Wed, 13 Nov 2024 21:58:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EEB66B008C; Wed, 13 Nov 2024 21:58:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B7DC6B0092; Wed, 13 Nov 2024 21:58:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EFFFA6B0085 for ; Wed, 13 Nov 2024 21:58:58 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6A616120F59 for ; Thu, 14 Nov 2024 02:58:58 +0000 (UTC) X-FDA: 82783192254.24.F74E451 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf26.hostedemail.com (Postfix) with ESMTP id 28D5514013A for ; Thu, 14 Nov 2024 02:58:21 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=bZaN2Pq6; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731553072; a=rsa-sha256; cv=none; b=VSTP6qMswHVeJIV4K/BLHP1QQ/g5tDWdCIm2gUkCwh9DXo5eOVpz9Xp8UbB2lnvc8iEi98 qvhHXjsyhW3CInJIJqvmUggPN+ZG38xdg2Aebpk5gO/afnidDnue+tloiijKK4lcPcJqP1 rf81JM4SXpCTo51w20YObrFLB/QkY5o= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=bZaN2Pq6; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf26.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 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=1731553072; 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=KRFiIYjYsXClQNA33ST6V6UAYzj5lmjJiOG5AbPovVY=; b=7lcUEZFVGehsBs3I72werNaRM77bZEv41RFwb8o/0ig4YOXFGTXzStDGrmkdXDJFW+uqu/ Z8S8nmdoBj7p0GdqBXcotsnbVna2JJTCZykjt9MxR+g+vynkQOZwpkZor28/yvUhcyrDUc XlE8eq13Uge0jYYnzWqKNNPM6Wygqok= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1731553130; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=KRFiIYjYsXClQNA33ST6V6UAYzj5lmjJiOG5AbPovVY=; b=bZaN2Pq6OE4+DEu7GbGgRso1iTLgtIk8N33w1NWUGwOr47gFqZpeZZCMgbyDnzROWjweXvL+z1AISb1For24eQ1SM0SO1GXfFmSoBYIqwy4LNPgqMkB206A56xJYWEQB9kwEO4HlUv1m5lzgqkREk1Lhd7UQnDSFZ2099wBflsQ= Received: from 30.74.144.113(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WJMcp8W_1731553128 cluster:ay36) by smtp.aliyun-inc.com; Thu, 14 Nov 2024 10:58:49 +0800 Message-ID: <498eb2ea-d3d1-4396-982e-1b81ec161a51@linux.alibaba.com> Date: Thu, 14 Nov 2024 10:58:47 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/compaction: fix the total_isolated in strict mode To: Qiang Liu , akpm Cc: linux-mm , linux-kernel References: <20241102201621.95291-1-liuq131@chinatelecom.cn> <055703d7-1434-42fb-8048-add21a9bd44c@linux.alibaba.com> <2024111210165296529720@chinatelecom.cn> <2503b955-79a9-4d21-9a25-34a6c33e688d@linux.alibaba.com> From: Baolin Wang In-Reply-To: <2503b955-79a9-4d21-9a25-34a6c33e688d@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 28D5514013A X-Rspamd-Server: rspam01 X-Stat-Signature: wiy8yxe8ggzq5u8diqwsixsagygnqh6s X-HE-Tag: 1731553101-337090 X-HE-Meta: U2FsdGVkX1+V+xNXX8E0T2+XUnDTa7/zrj+GVawvfdDtspAhcxClI+slpsyhkLwaOUF0pesU+k5H+FCXnmKDMKp++Nyj2YMtjTyKgBOQUQPSe2aJxhsq1kE4el7S04LayVWv9o6oycb4jtZ4qlfLV/J+Z+7U9YZ/hS+7UEvc1OI7whEh+SplTWlGtIIMSoGzu/vxtkdsqdvHadqHLvs1u+XVdau1utqBjQKSnhfBgEYHQaUqN3dvL9X2m3ab6yP2BOsrEWSMuOu0mv6J50aYSOhpRpEVy18H0D6B7x7/1lHR2elvziPHcsCYGeGFp+deesor7FW1Xm2zdy9d9E1UjaXHkORO1BdkQmTVB8XwWnuxCO6C1mhdpQt7A4iuaWtr47ypJhp6n0erUpBz7cOdDgFGnMqx/VHDsMdTLrPjDyaZSxzbtNXj0syvXq8Ymd3RLHk7VETqJqCy5t4mnt14kQceKy2ih3p3U/nxURM+ilH1sXDdoj0zDlzTe4kJ4wLGFLeoPFoCd2XWrEK11rCcxNJsag6W8rY/xLlr1CYvX7RCsohYOy+ElYWAMzqjiwsRtwKYeH7A8FhVviKr42TSVVTwgdXpBmUIhjV0pj5goCnGwN6cKBsHs7hzOmdqrjbto/oDGv7GCzixRScENKZn0MYLYI1mqXz4XtpChp817m3+8idAF4Qe28oKp8Y1M+zIWo61vU1GarsItP0qAYw1cmr23Je8fi/tzRCPKob3Xjwl07IFDSMtQ4Sw3Dn2/eAqrCjpcKBHHWS9c4zbDdxrQ7B/SjivrVxGPq7VqDgOUe8ernzoGGNDOYI4YMub97zfYSb+SM/rSFjYS8jKuChSshYRB42AY+0YCJ2ZL3R5aQIvf6VgxnkAn7fQaHrlSogXZs/Ey/WZ0ZAUNe5AkGSJuk7YWEay5S9Y78ondOWRjXTiCA50UUd7ocKjKNiIWzX6pwlW4yaG7YZLXLM/d+Q 7uNj3BZG ssj6lFMm899m4nPa3NzHLJbwngByo4LhqtdJFGHGAG7eM+UcjJhwYD66exPsjYy20YtzowlTL+kHKr0F/lgCa3Y7RcbO1IFPPlrdh+P1urMuCG/Qffcg3g58WAlOW/ARjGeLWS8PY+W0eOT+7+MyTweh/to0aDkNNfWBt885TSvdWHNJ6CX2rj58Sr4TaHxRzvEFehTEFDYxs9btzaiXnPKePzle6sLqA5zIg2+zRHD6zbPb1EkVWrQQJdhXGitcMfO/wJtxh0VhD3RGdlWO7AoNii4ddq2/iYonGBj/jO6vMTUuEQwfwu/Q9d3Go57uFgKH9rjWrM0rtmRTdwkDkzTpBjQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.007046, 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/11/14 10:10, Qiang Liu wrote: > From: Baolin Wang > > > On 2024/11/12  17:47, baolin.wang@linux.alibaba.com wrote: >> On 2024/11/12 10:16, liuq131@chinatelecom.cn wrote: >>> "We assume that the block we are currently processing is distributed >>> as follows: >>> 0   1   2                                                            511 >>> -------------------------------------------------- >>> |    | >>> |                                                              | >>> --------------------------------------------------- >>> Index 0 and 1 are both pages with an order of 0. >>> Index 2 has a bogus order (let's assume the order is 9). >>> When the for loop reaches index 2, it will enter the following code: >>> /* >>>   * For compound pages such as THP and hugetlbfs, we can save >>>   * potentially a lot of iterations if we skip them at once. >>>   * The check is racy, but we can consider only valid values >>>   * and the only danger is skipping too much. >>>   */ >>> if (PageCompound(page)) { >>>      const unsigned int order = compound_order(page); >>>      if (blockpfn + (1UL << order) <= end_pfn) { >>>          blockpfn += (1UL << order) - 1; >>>          page += (1UL << order) - 1; >>>          nr_scanned += (1UL << order) - 1; >>>      } >>>      goto isolate_fail; >>> } >>> >>> After exiting the for loop: >>> blockpfn =basepfn+ 2+2^9 = basepfn+514 >>> endpfn  = basepfn +512 >>> total_isolated = 2 >>> nr_scanned = 514 >> >> In your case, the 'blockpfn' will not be updated to 'basepfn+514', >> because 'blockpfn + (1UL << order) > end_pfn', right? And remember the >> 'end_pfn' is the end of the pageblock. >> >> So I'm still confused about your case. Is this from code inspection? > You're right, the situation where blockpfn > end_pfn would not actually > occur here. > I encountered this issue in the 4.19 kernel, which did not have this check. > I didn't carefully examine this scenario later. Sorry about that. Never mind:) > However, when blockpfn == end_pfn, I believe the patch is still applicable, > but the git log needs to be updated. Is there still an opportunity to > submit > a revised version of the patch? Of course yes, and please describe your issue clearly in the next verion. However, IIUC when blockpfn == end_pfn in your case, the 'total_isolated' is still 0. >>> /* >>> * Be careful to not go outside of the pageblock. >>> */ >>> if (unlikely(blockpfn > end_pfn)) >>> blockpfn = end_pfn; >>> So this can happen >>> >>> /* >>>   * If strict isolation is requested by CMA then check that all the >>>   * pages requested were isolated. If there were any failures, 0 is >>>   * returned and CMA will fail. >>>   */ >>> if (strict && blockpfn < end_pfn) >>> total_isolated = 0; >>> >>> If processed according to the old code, it will not enter the if >>> statement to reset total_isolated, but the correct handling is to >>> reset total_isolated to 0. >> >> Please do not top-posting: >> >> " >> - Use interleaved ("inline") replies, which makes your response easier >> to read. (i.e. avoid top-posting -- the practice of putting your >> answer above the quoted text you are responding to.) For more details, >> see >>   :ref:`Documentation/process/submitting-patches.rst >> `. >> " >>