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 C0084ECAAD8 for ; Wed, 21 Sep 2022 08:19:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38EF86B0074; Wed, 21 Sep 2022 04:19:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33F1180007; Wed, 21 Sep 2022 04:19:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2079F940007; Wed, 21 Sep 2022 04:19:03 -0400 (EDT) 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 12C936B0074 for ; Wed, 21 Sep 2022 04:19:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C71BEA02D1 for ; Wed, 21 Sep 2022 08:19:02 +0000 (UTC) X-FDA: 79935392124.27.7CB2D93 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf02.hostedemail.com (Postfix) with ESMTP id 620048000B for ; Wed, 21 Sep 2022 08:19:02 +0000 (UTC) Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28L6qYpn000762; Wed, 21 Sep 2022 08:19:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=saCynz8FRj5JHyMYWzHz9eoY3wv/ga8ektf+CZOKzLk=; b=eV6fvuLIiBTJTr/EIAOCoQV44n9/HlEb5i3Cj8N51FEfEIfLX7I+qcPKNNPyD7H7PZd0 v63NNH14rjAubF+4j3Rz7NFoNMGRhGfIzO7SLbSisxjOIV/FdbdHriVBQ8KW52iPK37m wXaZakDFH/z8ZuD81TRrpHE7xlnV4FeNnVK2vOtSYj4Y1vxQkiFd2wcioPq8S7dZbZnv NhFbcy63wtmBoDcjZMw29VrDArngi7c2P5fo0k3Wll8PU0S6ieV0g9hA04P4tVb6ijLm lwJ2oYAZvI+097FdLtWLyyAn+O/nDpn0enSQeyFrlxtQ9t0N1u6eNxLwbIquR1ehUQXo QQ== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3jq8wgc26j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Sep 2022 08:19:01 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 28L8J0l8030600 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Sep 2022 08:19:00 GMT Received: from [10.239.132.245] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Wed, 21 Sep 2022 01:18:58 -0700 Message-ID: <4c4944d7-b690-a8ba-5d93-cbd09b5a28ca@quicinc.com> Date: Wed, 21 Sep 2022 16:18:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [RESEND PATCH] mm:page_alloc.c: lower the order requirement of should_reclaim_retry Content-Language: en-US To: Michal Hocko CC: , , , , References: <1663556455-30188-1-git-send-email-quic_zhenhuah@quicinc.com> From: Zhenhua Huang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: kxeEL5JlX170mBYh6gBvLg_Mjxijn975 X-Proofpoint-GUID: kxeEL5JlX170mBYh6gBvLg_Mjxijn975 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-21_04,2022-09-20_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 suspectscore=0 priorityscore=1501 adultscore=0 mlxscore=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 malwarescore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209210054 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663748342; 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=saCynz8FRj5JHyMYWzHz9eoY3wv/ga8ektf+CZOKzLk=; b=GTexrfUSO92u3RMWEZhZAaPcaU57UOn6dRr3U067iXeKkSy5nBb4Z3hHlQ5S7TJIJGEi90 aNEDh4rtXECXHe0miTzxbH7w/Ov5438L0TLTCdgadrpCCQHAneCUL38PqPB56NCHlPC6QP oDNksEvui6RKXwPjok6r5VvTcn5DBqE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=eV6fvuLI; spf=pass (imf02.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663748342; a=rsa-sha256; cv=none; b=Ps6J3LcVwXOkUPTNcKNByh2AvXeK5Wwofxi05p03HU57ihlWOPz15GU/o0bRSGkczRIsrf kRzXYZCpXpv6cc1W3zevyd7BKmcNfR32te9Db1vsu0Q2d9MYcm8B1foc0h8QV55GWDKDVi TWDmc/nac5nQ/d2tBxU0AjDxKwa4VGo= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=eV6fvuLI; spf=pass (imf02.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com X-Stat-Signature: ekoxuathbqofy7mpz3n9jzeix5isfot8 X-Rspamd-Queue-Id: 620048000B X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1663748342-594599 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: Thanks Michal again! On 2022/9/20 19:20, Michal Hocko wrote: > On Tue 20-09-22 17:38:30, Zhenhua Huang wrote: > [...] >>>>> Also this patch doesn't really explain why it should work and honestly >>>>> it doesn't really make much sense to me either. >>>> Sorry, my fault. IMO, The reason it should work is, say for this case of >>>> order 3 allocation: we can perform direct reclaim more times as we have only >>>> order 2 pages(which *lowered* by this change) in free_list(8214*16kB (UEC)). >>>> The order requirement which I have lowered is should_reclaim_retry -> >>>> __zone_watermark_ok: >>>> for (o = order; o < MAX_ORDER; o++) { >>>> struct free_area *area = &z->free_area[o]; >>>> ... >>>> for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) { >>>> if (!free_area_empty(area, mt)) >>>> return true; >>>> } >>>> >>>> Order 2 pages can be more easily met, hence VM has more chance to return >>>> true from should_reclaim_retry. >>> >>> This is a wrong approach to the problem because there is no real >>> guarantee the reclaim round will do anything useful. You should be >>> really looking at the compaction side of the thing. >> >> Thanks Michal for the advice, I'll look at from compaction side also. But I >> have one further question, IMO reclaim(~2GB LRU pages can be reclaimed) >> should be more feasible compared to compaction(already tried with highest >> prio and failed) in this case? Could you please elaborate more...it seems I >> still not fully understand why it's a wrong approach to check from reclaim >> phase. > > Mel, has explained a large part I would go with let me just be more > explicit about one part. Memory reclaim is not order aware and that > means that probability of higher order pages are not directly related to > the number of reclaimed pages. You might be lucky and reclaim a THP to > form many order-3 pages or just reclaim those few that would create one > order-3 but all that is very unpredictable and hence we rely on the > compaction. Memory reclaim mostly assists compaction to allow some spare > memory to do the migration. Thanks for your kind sharing between reclaim VS compaction for high order allocations, Michal. Now I agreed with Mel and you, compaction should play a more important role in this.. or we have to use CMA instead. Thanks, Zhenhua