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 36CEBC48285 for ; Fri, 26 Jan 2024 10:47:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD9B96B007B; Fri, 26 Jan 2024 05:47:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A89D56B008C; Fri, 26 Jan 2024 05:47:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92AA46B0092; Fri, 26 Jan 2024 05:47:20 -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 8394C6B007B for ; Fri, 26 Jan 2024 05:47:20 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2C943A0F22 for ; Fri, 26 Jan 2024 10:47:20 +0000 (UTC) X-FDA: 81721135440.17.BAB1E33 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf25.hostedemail.com (Postfix) with ESMTP id B2B3AA0004 for ; Fri, 26 Jan 2024 10:47:17 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="TV YwDy3"; spf=pass (imf25.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706266038; 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=Dr1b+LNasWBfDiz6qm0FOfD2D0DAEk8L38V0AafYadw=; b=eqczpPJX2nHYqshx7UX/HUZOqScZ0i6fa9+6T8+ELTmpWdo3/M7cvbX9zsJxAMm787wNLy ztyorPg/3dFMgrNbXN8fDdwQDwZ9gVMMqEom0B+G9sjy4JM8qTAqGYY0iyLDg1f8081eVl cM+kwk9UHIwGEqHsPsz5surrf8VFaxU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706266038; a=rsa-sha256; cv=none; b=1feNWSi8+BA12ZA8nk8K9phrnpF7EftR36JnUPnnjvblAVpT9aRQ+XmxNx02HwkVlRhSC0 rkV6Qmm1CcwDEPIpTWzI7hX6yfBMl8eVE12bgYp3PZx3ZtPS/BZpaZ/cqKORR3aMU0qRWp fmQtiyY5Woj1butURXm6P2LEpDDXlaE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="TV YwDy3"; spf=pass (imf25.hostedemail.com: domain of quic_charante@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_charante@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 40Q4OuBC002099; Fri, 26 Jan 2024 10:47:13 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=Dr1b+LNasWBfDiz6qm0FOfD2D0DAEk8L38V0AafYadw=; b=TV YwDy3FFHML3PaoRSDH6ATY6Zx8W/OiAu5hJwCGX0BCFHm/9m9AZ9PDCK8Vsj7pL7 PM7DvyMPnHcxbPpMu6VzFMzPlrryjTihMaeIvTSbI3USy4C/Wp9XAFkBY4ONDAJh idzkegrFBuQA6qJowDwwUTSa9p6uuc2vE8Tg6gLGpFMolMRX1IZ7MPqJiNW0HOjJ yuYYHDZTDc5GaGeK3W5OZtQ5VSmD6csC8kjTyBPBPxb1izB32D948hf3kf4idNl+ SRrExxssctfKIA6tRJF334X9i1LQpQUHC1e6C0Fmvx1lSuLmyxJhDQqdpypQCBuw JOX2wc5OvqNxyCSgOqfg== Received: from nalasppmta03.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3vv1q596vt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jan 2024 10:47:13 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA03.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 40QAlCJW031039 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jan 2024 10:47:12 GMT Received: from [10.216.18.218] (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.1118.40; Fri, 26 Jan 2024 02:47:08 -0800 Message-ID: <5adb12eb-8403-5860-28eb-5f6ab12f3c04@quicinc.com> Date: Fri, 26 Jan 2024 16:17:04 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH V3 3/3] mm: page_alloc: drain pcp lists before oom kill Content-Language: en-US To: Zach O'Keefe CC: Michal Hocko , , , , , , , , , Axel Rasmussen , Yosry Ahmed , David Rientjes References: <5c7f25f9-f86b-8e15-8603-e212b9911cac@quicinc.com> <342a8854-eef5-f68a-15e5-275de70e3f01@quicinc.com> From: Charan Teja Kalla In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: juFkEb3_tBv4RmYroSjb6W-T0ad2YZ34 X-Proofpoint-GUID: juFkEb3_tBv4RmYroSjb6W-T0ad2YZ34 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-25_14,2024-01-25_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 malwarescore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 phishscore=0 mlxlogscore=668 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2401190000 definitions=main-2401260078 X-Rspamd-Queue-Id: B2B3AA0004 X-Rspam-User: X-Stat-Signature: dbcem8bh16sze8bqetbbdkwsadfiosq6 X-Rspamd-Server: rspam03 X-HE-Tag: 1706266037-648536 X-HE-Meta: U2FsdGVkX18DbjuQQYKn7I7U/DjliknVKwtx7tO6Si59CWoyJ603vZ8aVVxPcxRPCVUDfddSvM8S/drPJkAhG9+uEK9tNrc33UOQb7my3cZnUC4/a/K/JAtC95YTGn9I/6ArubpB+gLXdBI9N5d01o0XCekYFwOMLKASOpJo5s50aoEYyVcY2QwQ74FQAQlznvzjZ5dZdMAxtyWs0UI+qlvZ5fMIxqU1+Kfe4djfVn0UdO6Lk0DJN47TBr3VdPuCbQS1QG/dwTRXph+mYLpnIzD+dcgB3NXOtwqZLGxaepBv4iTJrvEUjXZ0B1Yacbe0iK+8V0+RtjAkOCjQqbWzxqqN0TWljAT06KMxp32lXuQI/+9ihHl+aEzOtHF40+I2ezTg2rOfrg+PaweIvmaDMYMg0HSXeDzQcAv7P64c/TqXGSD3R8i2kyh7IoFzWil3881bVnCcf3C2NrgcOLXvtbFsfY1SoA5xCCuY5fZ6dMX7q0Clct3tb9HOw4oIUspSKJpyCc6lGuRCgk0kOiKg32nkx3HMaKRpwIoCSG/pNefrwInZjnVamMgojqSnYwZQH+sXCD7FlDF2D2k8SOdIJpqfASTJ1VtVvRPfNrabNpQDwvmIu7Ka0WNi0XMhY4Tv6/FkOL4GYYic+qP7MFTohr1yquuUoeFSIaQTGrFLizAc8nVSOispuezWf/Z49vbQ9uHCP9UXMkgrFkBjfJ8xx8o6B4Io89+YkbJySeXqL3YXTqpWlbVwYfyTDpOiedvRMR49qbgBVgcucdACsPkBu9CrxZ7xZeCJGvXe19GGJbkXmKFR5aRdLoE47v7YSPNL8QpkX+ikD5TXaqXN8SgBxjb7hd3/c8JMwJ0GCYV2GOzamuK3tQqsCqqi+EzWA6yOzgP2KFs37hwY8ybAYy4/LcN7eU7E0NsoJDZH+sMuIAIzdR3RtTSLAEYan+3Qwn0NL067yuWI0pc4w0GQR/4 8zR3XGQ0 FwioT9VF35iHh5cGIg5rDPw8MppdVHNyHVp29GPwgdEfuGnzsXbkaAq5HlEEhCy+1MqDiOaPET7lfFOMvFNuyT7STRbHav2RJv6hOBLVsljypwCVzHzboMwEh5DbazxOZ/+hsxxL67ZR+eLaNNfaIK1n1L7JXcFNzspjysLwAL8Oxg6GciDunFcCsopfvbL/44P6ch6/kbotOb+e8BwXHmvsYBL2skWdNYxFmeG++L722hjZdeLanCL7BFpKRRIdX/JYSHbXbYbV2VKCEE24Nxhy0EvShJqUPipdwUwhpNPGoDNl4XWkfi81dkuDThR8QG+f/DAGIjZudFmLm9Apa2Kym+DpXB94G0uiu 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: Hi Michal/Zach, On 1/25/2024 10:06 PM, Zach O'Keefe wrote: > Thanks for the patch, Charan, and thanks to Yosry for pointing me towards it. > > I took a look at data from our fleet, and there are many cases on > high-cpu-count machines where we find multi-GiB worth of data sitting > on pcpu free lists at the time of system oom-kill, when free memory > for the relevant zones are below min watermarks. I.e. clear cases > where this patch could have prevented OOM. > > This kind of issue scales with the number of cpus, so presumably this > patch will only become increasingly valuable to both datacenters and > desktops alike going forward. Can we revamp it as a standalone patch? > Glad to see a real world use case for this. We too have observed OOM for every now and then with relatively significant PCP cache, but in all such cases OOM is imminent. AFAICS, Your use case description to be seen like a premature OOM scenario despite lot of free memory sitting on the pcp lists, where this patch should've helped. @Michal: This usecase seems to be a practical scenario that you were asking below. Other concern of racing freeing of memory ending up in pcp lists first -- will that be such a big issue? This patch enables, drain the current pcp lists now that can avoid the oom altogether. If this racing free is a major concern, should that be taken as a separate discussion? Will revamp this as a separate patch if no more concerns here. > Thanks, > Zach > > > On Tue, Nov 14, 2023 at 8:37 AM Charan Teja Kalla > wrote: >> >> Thanks Michal!! >> >> On 11/14/2023 4:18 PM, Michal Hocko wrote: >>>> At least in my particular stress test case it just delayed the OOM as i >>>> can see that at the time of OOM kill, there are no free pcp pages. My >>>> understanding of the OOM is that it should be the last resort and only >>>> after doing the enough reclaim retries. CMIW here. >>> Yes it is a last resort but it is a heuristic as well. So the real >>> questoin is whether this makes any practical difference outside of >>> artificial workloads. I do not see anything particularly worrying to >>> drain the pcp cache but it should be noted that this won't be 100% >>> either as racing freeing of memory will end up on pcp lists first. >> >> Okay, I don't have any practical scenario where this helped me in >> avoiding the OOM. Will comeback If I ever encounter this issue in >> practical scenario. >> >> Also If you have any comments on [PATCH V2 2/3] mm: page_alloc: correct >> high atomic reserve calculations will help me. >> >> Thanks. >>