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 6E39EEB64DC for ; Tue, 27 Jun 2023 13:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB04D8D0002; Tue, 27 Jun 2023 09:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D60A08D0001; Tue, 27 Jun 2023 09:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C27F98D0002; Tue, 27 Jun 2023 09:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AE2E88D0001 for ; Tue, 27 Jun 2023 09:56:44 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 708D61609EF for ; Tue, 27 Jun 2023 13:56:44 +0000 (UTC) X-FDA: 80948678328.14.CF75E3D Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by imf08.hostedemail.com (Postfix) with ESMTP id 08548160015 for ; Tue, 27 Jun 2023 13:56:40 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=DKQj5gvJ; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf08.hostedemail.com: domain of quic_pkondeti@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_pkondeti@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687874201; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4S2U3hsLDipgOOGGVwmjrTLzrZZ9eXd9cKZq+iimHYM=; b=08BF1maMqYaQBGspC7StayxYROQ4PpD6RujiT8c356qSTLM/ugcAyrbcNgSLTfyF22FdbV vp0a0x8Vibul7AfMBZuUyk22G+fJ08RO14+rnF1Uu++OsfPZ/YlSytLY5GFVCYiBwiYi4r +Y8ByhpeQeazwZ6+SsnLazjj/bmEUsw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=DKQj5gvJ; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf08.hostedemail.com: domain of quic_pkondeti@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_pkondeti@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687874201; a=rsa-sha256; cv=none; b=d5vmkKQCpcayzHfNpJp9zM4NDells44Tz2Tc2lIMSuGlaQO3i8bEiETJEABqQtekmC2awW llaLDeCUoWSfFREj9Q7yYMr9y+PNUKIIjGsnu/xBlmnY++yKsej7TKcaxEbJq6Ua9oxFuU Kn54RQhS4gVAUYGlwfnXo1aqXe/x8gY= Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35RD0aax005898; Tue, 27 Jun 2023 13:56:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=qcppdkim1; bh=4S2U3hsLDipgOOGGVwmjrTLzrZZ9eXd9cKZq+iimHYM=; b=DKQj5gvJJT0ZLNqzSuO+54SwWWtKZelyhYtKMyy52nOKHV7gUe89puLweLbv+mdX7LI+ 1wjD9zMPDdaVU0Bntgqz+/a+T0UaTrjJljfMxQprCUM04XXGis805zGb5/qjIHPnWnS2 x2qZJUHq1eRz8nWQUg2jfChudIsMKy9fosWfCrfzzlv3T33XY++qTX74WmZ4Cr1MvV1Z lmkdaZ5Ol0q7H5avDIfYHSSQbyODS/CQmsEJmhq8JaHH4dL7/saFnCBbE5qjUCtqCRf/ qcfdzvgWHdHv1AQmFvIPA+ZR+lzOWghAFFq/l+I3qnQ53epTQo2JB/qZANlu0tczzIQP TQ== Received: from nalasppmta05.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3rfuhj8qkw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2023 13:56:34 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 35RDuXmA017991 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jun 2023 13:56:33 GMT Received: from hu-pkondeti-hyd.qualcomm.com (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.42; Tue, 27 Jun 2023 06:56:29 -0700 Date: Tue, 27 Jun 2023 19:26:24 +0530 From: Pavan Kondeti To: Charan Teja Kalla CC: , , , , , , , Subject: Re: [PATCH V2] mm: madvise: fix uneven accounting of psi Message-ID: References: <1687861992-8722-1-git-send-email-quic_charante@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1687861992-8722-1-git-send-email-quic_charante@quicinc.com> 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-GUID: sLP3apRvmAXLgRyIILXz4HttgIauD-BR X-Proofpoint-ORIG-GUID: sLP3apRvmAXLgRyIILXz4HttgIauD-BR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-27_09,2023-06-27_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 priorityscore=1501 bulkscore=0 spamscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306270129 X-Rspam-User: X-Stat-Signature: 3rgmwaqkxrmkcsbta9oo11bwq9ieahqn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 08548160015 X-HE-Tag: 1687874200-527724 X-HE-Meta: U2FsdGVkX1+xHRO4noZtECxLsFChPsOVEE3kHhfhCBvIX0snJXBlEgqhixHVBbpc+Cfd+V4mfP4rLyI8T2y6V/z7xCy4Sqn160dEKceq77EwA4WaMi6XjEPKTHq5sQblT7kyUfchyiQCCf5u6Gb0JkLkwLqZ/ZZU2yy8JW9PsbwU57PmElEhD/DUlhkTMpSZq+OHlpHikA/felLYu6dwyENUKNgQiFT5WU1UjcT/0QwfD3JUPu1EYcES7sr6qlNqzSsPC+sFPE8eDWwm5JGWVuo5jH5RbQ8wjQnoXEkTpN/C8S6Aykyh1zUFTxzoq0X0H0La+AfTbgJALAXQqCZcdn8T4RVjbyoY//1ROKq3iOluIJLCpzDVeGTEqd6gxodWkGYk2nPvdQzslNktb6Ze+BxKLH93NYaDT/uI7wYku1lSFKDWTv3ZD+DzAAxSMHVLHFV/9FgmhF2Dgf3BP91H9oum8L7t509Racu6CfzrayfPngQCCi0/zSCp3Xho+tt1AgDSqa54qeNIWEtw/QIpzaqce6RqZqwwn0pWo0cP1KeH8g3qXnDB+NVvNVpSv3p9bGpvF5pMR+SgwktiJBkb2KJdWdK1kouhniHZXLEGkZxEqo1OzvTXFd8UBvbbyPZ/bGQd9LP5Tu0x5hAB6WAUSpTz9jpsZAkCQrPcxTY58WPGcd4xEDnVSDmHeP2IbWORS0U+APy+o1Bmrgk+waxwpr1TPwZchMlWiV/qdBdtVDBfxEIgOY9F8IPrwUDmFAV01eInQu5gj0VBdTwlXC8M+nKvGEuu+aruMKkHamSQg/s/Op3fYrLh0CtsdSkmfaML7Bl/40+KicZYcltyPv8Tq6rylkzkn+M1wtq2wDg1uSLjnyDv3lPZS+W8xZE8lP9L1f5rKfdcTRCeWpDQCE1ktk8HMYGDWLVJL3FMJHexsmGdpYjCTAoM6O10ncGPcijORaauBMqhXsN4+B5nvCp DKU0MwA5 j3Oh4FnEFOxEdzdLa9+fPJ/Wt2qmLeWTbQBaU9MRhsFDng8XBFNQcafbg2GDLonnh8ffHVbY2VDEtGbLpaBPNkxsDPJGA50KN5Kty5PNPf4GE2juTFPOSz3UHCJrKlPTTNFlpyFvu35F1mQqjInWiztIdZDIBFy5jOr6yIO9SSyEyySiK52IBh+EF0Qh/x7Lxm2HZ68o9t4UN2PbsXN7WnBELNGtSk6zvOSR7IFxopSV4nMI9UATCC8WwuMmA594DKFMREAlS/HWmhQdBI1MiQ19XticI8fogKwuFo6XPRt8h2I6h+9+EJlkqh5/iyoGWh5PS499+xf3gjBj4UOiBod6sQJjqsKRRxSBX90o3mXijZJnoO78cJMD7VID5lTDeut67eeZbu22F8lfFow8+ocUEhYd0SNupV3TMwMIuFEMn82p7+wGLpatR8qIaRYc6ulQksjgn9gNDQzz7JIGKF0sERA== 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: On Tue, Jun 27, 2023 at 04:03:12PM +0530, Charan Teja Kalla wrote: > A folio turns into a Workingset during: > 1) shrink_active_list() placing the folio from active to inactive list. > 2) When a workingset transition is happening during the folio refault. > > And when Workingset is set on a folio, PSI for memory can be accounted > during a) That folio is being reclaimed and b) Refault of that folio. > Please help me understand why PSI for memory (I understood it as the time spent in psi_memstall_enter() to psi_memstall_leave()) would be accounted in (a) i.e during reclaim. I understand that when a working The (b) part is very clear. > This accounting of PSI for memory is not consistent in the cases where > clients use madvise(COLD/PAGEOUT) to deactivate or proactively reclaim a > folio: > a) A folio started at inactive and moved to active as part of accesses. > Workingset is absent on the folio thus madvise(MADV_PAGEOUT) don't > account such folios for PSI. > > b) When the same folio transition from inactive->active and then to > inactive through shrink_active_list(). Workingset is set on the folio > thus madvise(MADV_PAGEOUT) account such folios for PSI. > > c) When the same folio is part of active list directly as a result of > folio refault and this was a workingset folio prior to eviction. > Workingset is set on the folio thus both the operations of MADV_PAGEOUT > and reclaim of the MADV_COLD operated folio account for PSI. > > d) madvise(MADV_COLD) transfers the folio from active list to inactive > list. Such folios may not have the Workingset thus reclaim operation > on such folio doesn't account for PSI. > > As said above, the MADV_PAGEOUT on a folio is accounts for memory PSI in > b) and c) but not in a). Reclaim of a folio on which MADV_COLD is > performed accounts memory PSI in c) but not in d) which is an > inconsistent behaviour. Make this PSI accounting always consistent by > turning a folio into a workingset one whenever it is leaving the active > list. Also, accounting of PSI on a folio whenever it leaves the > active list as part of the MADV_COLD/PAGEOUT operation helps the users > whether they are operating on proper folios[1]. I understood the problem from V1 discussions. But the references to "madvise account such folios for PSI" is confusing. Why would madvise(PAGEOUT) be accounting anything related to PSI. I get that madvise() is messing up PSI accuracy indirectly.. > > [1] https://lore.kernel.org/all/20230605180013.GD221380@cmpxchg.org/ > > Suggested-by: Suren Baghdasaryan > Reported-by: Sai Manobhiram Manapragada > Reported-by: Pavan Kondeti > Signed-off-by: Charan Teja Kalla > --- > V2: Made changes as per the comments from Johannes/Suren. > > V1: https://lore.kernel.org/all/1685531374-6091-1-git-send-email-quic_charante@quicinc.com/ > > mm/madvise.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/madvise.c b/mm/madvise.c > index d9e7b42..76fb31f 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -413,6 +413,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, > > folio_clear_referenced(folio); > folio_test_clear_young(folio); > + folio_set_workingset(folio); > if (pageout) { > if (folio_isolate_lru(folio)) { > if (folio_test_unevictable(folio)) > @@ -512,6 +513,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, > */ > folio_clear_referenced(folio); > folio_test_clear_young(folio); > + folio_set_workingset(folio); > if (pageout) { > if (folio_isolate_lru(folio)) { > if (folio_test_unevictable(folio)) > -- > 2.7.4 > This is not limited to madvise(PAGEOUT) right, anywhere an active page is reclaimed we have the same problem. For ex: damon_pa_pageout() and __alloc_contig_migrate_range()->reclaim_clean_pages_from_list(). If that is the case, can we set mark a folio as a workingset when it is activated? That way, we don't have make madvise() as a special case? Thanks, Pavan