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 2930CECAAD8 for ; Wed, 21 Sep 2022 08:12:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 672F3940007; Wed, 21 Sep 2022 04:12:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6223B6B0075; Wed, 21 Sep 2022 04:12:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EA2F940007; Wed, 21 Sep 2022 04:12:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3EF436B0074 for ; Wed, 21 Sep 2022 04:12:23 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 05B661A0ED7 for ; Wed, 21 Sep 2022 08:12:23 +0000 (UTC) X-FDA: 79935375366.12.3999D71 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf20.hostedemail.com (Postfix) with ESMTP id 917821C0020 for ; Wed, 21 Sep 2022 08:12:22 +0000 (UTC) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28L7I2S4011832; Wed, 21 Sep 2022 08:12:21 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=5KszSir80/voBZhQwcu369BzTzszQJWePeAn9MBxwZw=; b=bLe9tfHOh6HxIRu6ZcsjbbDUBQj/UClZE9qHZU+NsFedJB8jQ5LGdPgG6u7sRFpZxAbA vC/yKhSx8Wx2SBfFQPxSvv9aucdTq7QnwLTrYcgJ43OcFYfrbQDYP/KB9cs+t58Lax2G LKz1n3dFuXCLxICAS6aVXR0Bo6jgM/3ALOWqQbh3A/cB+pqCWrV+uaRwOfkK77vzbqM/ EyDBLvdv23a9Ev98DLmKtrz7IUtZ2jXGqaDkHf2U53YzsEveXoj6c30e18NiDzWJxlYd N6tx6PYE4zHJB/VNdVsrhefXKv04jmRg7otE2xRybd4n0dIFThq+In9uYlCc0Mbg1lcf uQ== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3jq4r0cv5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Sep 2022 08:12:21 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 28L8CKY6015552 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Sep 2022 08:12:20 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:12:18 -0700 Message-ID: Date: Wed, 21 Sep 2022 16:12:16 +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 To: Mel Gorman CC: Michal Hocko , , , , References: <1663556455-30188-1-git-send-email-quic_zhenhuah@quicinc.com> <20220920110218.oegqcgvrscwecgtz@techsingularity.net> Content-Language: en-US From: Zhenhua Huang In-Reply-To: <20220920110218.oegqcgvrscwecgtz@techsingularity.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) 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: tjDINbLKoob4gFwJ5ie5YZ3-1BvcTpnY X-Proofpoint-GUID: tjDINbLKoob4gFwJ5ie5YZ3-1BvcTpnY 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 mlxlogscore=999 malwarescore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209210054 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663747942; a=rsa-sha256; cv=none; b=F5DcgWvnS8RW/+4eTtI+iemZEFY1JGGggE3fnqZTTrzBBospmR7MUbeNUnwQL0Zgwi1Njp ryiUN1qGOSQz3GCnZWX++OKVbvsDHaxUuYByQ5UdW6FkFxdFdR0uxN/hwzBYU6e+0ghYhP 285u50zrxFNLEXq4NXvzUDMpwzoR0C4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=bLe9tfHO; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf20.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663747942; 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=5KszSir80/voBZhQwcu369BzTzszQJWePeAn9MBxwZw=; b=srWtX8wXTrQRk9tPJZHULrIKbng/vaFe4nUkUXZUyS/0GfC2xNQIUNBUZqI5hiWmXbEUBa WbG83e2jqwZjI1ljIiMsjQRLcYJ7ZNDjw9nKgnCyo2+5nYbX98KXILoyok0zn25S9hrRZ1 a9qvgaoP75xo2x+2Pj4m7WonTDvYluc= Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=bLe9tfHO; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf20.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 7soquboje64z5spyh51djdwiccxs388d X-Rspamd-Queue-Id: 917821C0020 X-HE-Tag: 1663747942-761776 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 Mel for your detailed comments! On 2022/9/20 19:02, Mel Gorman wrote: > On Tue, Sep 20, 2022 at 05:38:30PM +0800, 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. >> > > Because it risks major slowdowns due to excessive reclaim. Early support > used "lumpy reclaim" instead of compaction and resulted in major stalls when > trying to allocate THP resulting in THP often being disabled. The success > rates were great but systems could become unusable for several minutes > and ultimately this resulted in compaction and the current backoff logic > of reclaim. Your scenario is similar, you want to aggressively trying to > shrink slabs in case an order-3 block of pages gets freed. It might succeed > but the system grinds to a halt with excessive re-reading of information > from the disk for other use cases. Thanks, I've also noticed. Contiguous reclaim obviously enlarged the time to OOM as I saw. > > Your focus likely should be on reclaim and compaction aborting > prematurely because free CMA pages are available at the correct order > but the calling context cannot use CMA pages. > > It's strange to hear of a driver that has a strict need for order-3 pages > being available at all times due to a lack of an IOMMU because that is > going to be fragile. One point of CMA was to carve out a region for such > drivers so they could the contiguous regions they needed. I believe phone > cameras were an early example. If your driver has strict requirements for > high-order page availability then CMA probably should be configured and > the driver should use CMA. > You point is to avoid to allocate order 3 unless that's really needed. Got it, thanks. Thanks, Zhenhua