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 0B8BAC54E58 for ; Wed, 20 Mar 2024 12:31:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BD066B008A; Wed, 20 Mar 2024 08:31:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 694FC6B008C; Wed, 20 Mar 2024 08:31:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E7856B0092; Wed, 20 Mar 2024 08:31:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3B1976B008A for ; Wed, 20 Mar 2024 08:31:33 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0FCE5121347 for ; Wed, 20 Mar 2024 12:31:33 +0000 (UTC) X-FDA: 81917353266.20.868A2BB Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf25.hostedemail.com (Postfix) with ESMTP id 42D9EA001E for ; Wed, 20 Mar 2024 12:31:27 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JGMPM9Pn; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of aravinda.prasad@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=aravinda.prasad@intel.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710937888; 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=SMER5pQnh0Rjqc6NfgwWO9pfWBCvMamsBb1C6JvPvpQ=; b=dM14FZpllImYIHyML5JBakj5nu+oUoPdDeXarESvcPqt1w3QyXg8gZFgj2DtQJz/+rC5eb MiXjw8T8tmuLQJdtz5xgRUnvzIRgC1nGW8Fol/TvFAEH88tpd3KfZKKepsJmmud7ojXtBT SjGYo2WkeA6V7dc6qhS7eDM8psDgg6c= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JGMPM9Pn; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of aravinda.prasad@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=aravinda.prasad@intel.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1710937888; a=rsa-sha256; cv=pass; b=Ftel4r6saX8kx8VZmWEjhxel7R89A48BrMYYOTtppMyL5nfKaxUPzoO4/IzFn3MC36Egwi Q+1omPOgce0GXyAPpvKMjsniDWUaCGTW2Imzx6FOU329V7+W+/NXHXIti39U7RsKXfVlRs NyBqu+mRUs+Wa9lF7Y8aNFUKX+kDGCI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710937887; x=1742473887; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/vfyFUEnNyyMQoCe0NVRyRb6AtPfbi1M0UPNTIXmHS8=; b=JGMPM9PnHzlzTe7v4gUfpBjyegDgmB2FfYdqucnn0+fTZzhBCIBfB3O5 FnRTBV/nTdXjL6015W0J5EAk9fjLuscUhseHQ5Q9RLf1WYh0OmIxrxlF+ kXdT9zfZc0jENMo5Fv+udF718iO9JwhHes1mTOuDSgVmwuWmjlfg+uxUO /1EFbqfd4sDq/qzB0T3jeMMkW8A7fjHn8pjR2rXf2my25rQnGPkfwy3Bn 3Su8+ohKyq9oEqFF3dm5TdHTDylV+nFIxWgVTra2cEji/z0ipU5tiBSaI DlID3PW9sW2ubW/PKd3H03+FINApLtpAtqaZg9iwdcOpSimY1cPmCFbma w==; X-IronPort-AV: E=McAfee;i="6600,9927,11018"; a="28332949" X-IronPort-AV: E=Sophos;i="6.07,140,1708416000"; d="scan'208";a="28332949" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Mar 2024 05:31:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,140,1708416000"; d="scan'208";a="18862649" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orviesa003.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 20 Mar 2024 05:31:26 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 20 Mar 2024 05:31:24 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Wed, 20 Mar 2024 05:31:24 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.168) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 20 Mar 2024 05:31:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZPhAbh4BdBC6w46e3B9pFzG9cEDp2T4Fweu8BfExkoMRt3dRNKyuOWfHPwniYUEdp9SfItomK/57r9jxTNBfqBiee6mRXMA2irgIbsxFcYmb2kSvQsCkIMFrs/KhVimBpH3onrHksINUZyAnLSswH2MXLVnQF7SUpe5PSV0th2wp8GUf+kqSLqisHq9pJekXGA5P270jrwSWtKeEvEMPul74W9e2qx9cQetZ6q/6StZVYSeybfnf8pTWTzCKEKH9qvE/eHSbZNLi8LAP/ZFgusUVyMyQ1IDOved75qzxAL26AtlwJvlxehGu2YJc9lJ0Zg+V/l6xzYUpNChqFSUNVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SMER5pQnh0Rjqc6NfgwWO9pfWBCvMamsBb1C6JvPvpQ=; b=OVOOl5/OLKcOTTBmq6uNQqyUkF0LgnD58tyLNKofAitJeWDvi/l+XxMQfZeRpMVZfSokHvpYo+EsV8shGjM61kXu2W6xSU64OCHV6Pt2hKBisi+SqomXG5msisSAyXoQ0LQ0736aJ4obRrLOsbc2H1ZIeyYslZDxc7ylFEyBI298OT/KTiRbSoFbIvYqH6ru1/18/LMmYbs90ztOj7zRhbLWi7kuQkn3xeGOf9rbk3mSiTCnx+YnC2wNFmKZg+HgU/hE00HCOAQIu/WzU2024PkifnqVZ8jrpaEkVKVMFQbMEcErTEvGY5Q4J90w7Y7Cou5DrZhPTFVStIeq6aWvAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from MW5PR11MB5907.namprd11.prod.outlook.com (2603:10b6:303:1a1::13) by BN9PR11MB5257.namprd11.prod.outlook.com (2603:10b6:408:132::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.12; Wed, 20 Mar 2024 12:31:17 +0000 Received: from MW5PR11MB5907.namprd11.prod.outlook.com ([fe80::bcbf:4501:30f4:843b]) by MW5PR11MB5907.namprd11.prod.outlook.com ([fe80::bcbf:4501:30f4:843b%4]) with mapi id 15.20.7409.010; Wed, 20 Mar 2024 12:31:17 +0000 From: "Prasad, Aravinda" To: SeongJae Park CC: "damon@lists.linux.dev" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "s2322819@ed.ac.uk" , "Kumar, Sandeep4" , "Huang, Ying" , "Hansen, Dave" , "Williams, Dan J" , "Subramoney, Sreenivas" , "Kervinen, Antti" , "Kanevskiy, Alexander" Subject: RE: [PATCH v2 0/3] mm/damon: Profiling enhancements for DAMON Thread-Topic: [PATCH v2 0/3] mm/damon: Profiling enhancements for DAMON Thread-Index: AQHaeTeYeVMaFIFnV0yMrKTBAlKavbE+h/4AgAIFciA= Date: Wed, 20 Mar 2024 12:31:17 +0000 Message-ID: References: <20240318132848.82686-1-aravinda.prasad@intel.com> <20240319052054.100167-1-sj@kernel.org> In-Reply-To: <20240319052054.100167-1-sj@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW5PR11MB5907:EE_|BN9PR11MB5257:EE_ x-ms-office365-filtering-correlation-id: 62415b93-d340-446b-8b45-08dc48d9a3c5 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WZcUQyDeYxQYSSinpq4GTRLZ+CeS30e1DbZqOKFxvLFLqvJun9dX5yIv6a/RJgijkpUbie04Y0HQF1r38iG+lbCQyyuXBUX9kmhOme9rMf8RQ8lx4BOn8Cqem88RuIqbGAPQrBzh39HRpgukVIsEZfnKCrTogJUm7/3+vN3v8eZ4bFyHOAzOGh8OaNwjV68wQmyDC3QB9vj9LBi+EY/MmFHxLsSs1X+LjtJ6Ug8QSJnMZ4FGNM2fg7zSqnqkvEGGO/2zqD9mCFFwsPwIUsxOZmVSglkHh//4x8x4id3xINaZm2lDNOz2zrzhB07NkG38QirTT860pqcsXH2xknZBvDrqiE4n7v3Z6qOFilguGgBuTNWzWrWa89TXqwtsdIgQzTdn7U73SCVw3qNAo/ZS1wZPuz5cN7gS0iXMoy1mN3xFxx3X7YPJbKtKUu/YEXcxrq8MO/0Dp3Zik81ay6Fe5A93rVw9IMnpVFRQwOZLpbLq/VeJMQLJQaGf4iovVTnteHHZI5rVXkJX1uuQZbroT3ybW5ADXvClVfTBtPW47zS5seCFWBXfcXYE1ImCV2d5NiaqnrwQzW+h4GSSMWq2uxRuLEhM0lRnLj24b6JYS9oSufhV16AlI5L9FV9AGkohfRJbkApDfZlFzhg5iYNXF6h02VavBRCCZSTsLTyf4Me5aLUebpE6/jgTQffelJVv x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW5PR11MB5907.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005)(38070700009);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6LX8PS8AgSUIf2j90KrErpZYY95KBhKugFpuXuRmXdl+q1yr8OihjFWsYEee?= =?us-ascii?Q?pqi0de+kHaot6j+kdeTXGiB5E+xsR39CeanU8H/5P88IYUMqBvf2yTlZ6Qk9?= =?us-ascii?Q?Lvmkw5fAmfUAKarNkKR2Xr+AssfInCtnJvGo21lYAhZtU42Wbm94LiVvVEQF?= =?us-ascii?Q?O41moQKD+cHarSe0kW7st97IFuqUARf2jvyeYcdFKHqa3PL8twD2/0PQ88sp?= =?us-ascii?Q?NfPf3SXUBc4HqiLg9jwm8s/i/bjAQkV8rzUZrqMArAFIjkcaB4IRpk5v92pA?= =?us-ascii?Q?1l/iIMFKL7VxoK3aVPXcWXiu4UOW+rU/B6HHMGrOy+n71c1eRbDFEfkaUpLl?= =?us-ascii?Q?ck9ajYCQBc/+j26ZodQEOhIWeu8hmSlbsETVFIr45ZjL3u9rzOMFGe69z1Ie?= =?us-ascii?Q?4VAVClKcAYvL5oN2X+prfBLVb0donjWHlZeC7Q/vsLaR/Tezshd9/mj0e0bX?= =?us-ascii?Q?ChqhkQEXoQVkRwJ4BkrROTB/3bmxC9U2s23hrUSp32/d0/wi2pwIIabJ/c21?= =?us-ascii?Q?xauvLGu8DexOWC2vc69PSGZy+CGMdfu+skJi2XYgI39Hd/WVnasvHrODr+Je?= =?us-ascii?Q?5jGdhMEON/ZKIA+hhzgeMUDjemoM5N9P21+E8QRK4R4n/7JPT+11+y4nO8RR?= =?us-ascii?Q?6HQnyfwcOCiWI+9NIzVXRxeizX7TAMdoP/CgBE0gMFwG5+ZjZRW+UMyTwPDd?= =?us-ascii?Q?J/U9HQv9VRWiwLi4botvWa/gQe+vWTbx6Fo7Z7nF7Zs8rVv8S4Z7/7hmFsZ1?= =?us-ascii?Q?f1WUlSW3D1/dRfPN+3wVo8wyOehDk7ZSTxLI4KWKMe4+V2eM8R4ssdOmvPg3?= =?us-ascii?Q?AHbP5ooIGLCVFTZFGBDyhyfmZrGzPpZanCzN1ojcRHcrwkajtHawfw14QMM1?= =?us-ascii?Q?1+oya0PersUMYqBG1kysNt56IqS6inXYoEuztbtL1j3jLyC/DmhZmYBh3Vgi?= =?us-ascii?Q?LVTIzmcPKvLIPbu/kxNJI7s2sev0I3u+8G4JphLOxJ8H8WNRmohbuFqHVaYs?= =?us-ascii?Q?PWVb6BLRpyCkZkTZfQIg+VwhjyNpJQnYfmEZCJSg9jLK2Eu0Q1hM3IA0dK12?= =?us-ascii?Q?BYr7nOOUKnf7DX/EgxiMABnxTF5/i5xhNrrXmu9PEeQQ8zeKQrLMZiK0NjIx?= =?us-ascii?Q?77c8CFgtlo1iHMFMm9wenlIlWEpOBONlCYzoNpAWYceeTCyLqjRY+i4mg1j0?= =?us-ascii?Q?qEvBM7SUGXAkjUfTw0FA7YzeagyL6RLIY3WoAUtiePHUBMr/clfeagDJcAI0?= =?us-ascii?Q?hzwW2w7iB+lOgUU6CndEOMv0zY/vMzniJ8L5g4Rk8pfC2jqYKt+ErC9bGtA0?= =?us-ascii?Q?StfXLxGySSL6evENecBn7pT8X/PNngcK+AMndtyW+k3ky9ZzYkD29Ay2NGEF?= =?us-ascii?Q?NVIhihCHf2Cx6E//hWWnqpawjPNCBv5HSaXIMTb20pE2AgjMt3f8DucestCt?= =?us-ascii?Q?Y5/cMxob3pIqxgtNADvQsDOVfOlQlDAgF1RlOWXuVnyt0K1wnX8OKo1DLEzZ?= =?us-ascii?Q?8MjXlWEV+t0AykvYUbCIxDcyy7QeczsRUb4Vu7c53ErbJyU8HH2+HiodVeg0?= =?us-ascii?Q?PgMn9coVLqsRaqiXZNko01GgSeDQns/Q9QZRzPCT?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW5PR11MB5907.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62415b93-d340-446b-8b45-08dc48d9a3c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2024 12:31:17.2051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8qoX0cJjbOPNLqrapUoVw9VtT8b5y/8GzHxz0VZO++eg2xlSEviML5Pa/vCpp0M3EYX4eTk1dAeIvtZxAnSZhYDDXARhiVaQxaUZmXZbvJ4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5257 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: 42D9EA001E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: z54hc6rdy59siz5uqewk4pgywss6qast X-HE-Tag: 1710937887-700692 X-HE-Meta: U2FsdGVkX18kZ+bGDd+ijh05WGsfI3WoqApZm26nWBY0uxmtaUVkBVZEbA7yt6G1Xrr4PIfgQ2rqq91xGR76ojSxQ6fnOeYi4giX4V3BIY4VLfo8KsGIl3LRkgUI63PM2u0Vbeg4qx8coDu0TSflBo0M3LHS602PHVBKybOeiDK+kTkeb64yc1gEggM8H1+GgNGXayPKBrsmBz29Wz181ppJldIA/IBxH8zMejZCK1vLTdXeOxHvF4ry3IainsCsVDgYnkq+E2vO7tSyVYVNGAE1HibYB3QmYNZGI/gMmcpLa8V+pX0PW0lQccxJv4ngqVHHcVybmFblX1uN9uMUuJEN/xX+g2KG/z7nK7Zir0HZMjyHziXNc7EhzC7pwVEIh5RwE1JPdAev5FdEIE9nYQFpkyf/AfcVUAQPeZKzMhsnxOhUFFlo7hv9pmWs6FiV1zvAW1d8PzcvivrRIe4pCE6MDljkTlTRXugCrbgG0e5L+8g702go9eLXBQhopv8jkAcmKRW7F6/nN46PFaK1ERJUjKdavTse0uERj1K8nvA1UuK2ZsuGQWNz4kAbc4/jhMaAPBprw4oMxhi1tPKpflVI3UHW2BBc5S6zJymjERbXD6RwqIH5a7gNCS43VymtN5OoqT7PjE9rli/a/rEJGDJR5SeCDN5l8E7AuN6q6fhliivB8sipizNGaydA+N+5YLIfvZYK4M2kfKvCIFjssGKKBBo25G7rpmi85hoymBVgMzyow3HF+PzL149eF1g++YxT+THUZFDlHNt3DdhDXr8BLiIXzKazboUZy+4h3vOSq8YLlMBA4gIhg0FKjbN1uwLLKpMq/hQhRSkUfzytMpyuvBjYnB/VTNx9tvKTKW6xiroZQBSp4PcjIYcDXxdjVz1xjnHylgrW79SgEWKviZkxM3tcPmcIE5LYl59B9vn1ihxAkGTHLx8lrGjnYid1XQC+kUf1lx+U0+0BEK9 h5MEXeSz jdRTf6w7c3TVRBpc2Ubc3dCLfvlGisYivpZwMCOK5PWJMP7EnZCFiKs+M7XEJTl2rN7gfm7hAKNIiOOebxFIzwOcu6A7Lw88Li8z194e9byFFMpc47vD09c3LU9eeKagyNFTNQ/eoK6SjnJUkKBq41HsCk90ThJMOx4iZhDmYeAEBBul8rDCOlzvosQw36FNDt46aono9Yw2s7C/w4m477FQKRu/BBxB6Ljk06isb6PyOhDCRWd7759guVuooO+ES7JMTTzMYXT1Tc430eWaZIGBz3gWNL6dgWiXP3mOx8yz8HiLU9etNrr/IdjF7kUcdyiuW3plpRa2qA3kZlfJv1SWNvIQWhjyLHdYvhzmpQrbza/KZJrxVRB78WLckrkiw0Mm9IlloJO7N37tyWLfoaKg51NQK8DcSgYMIjstk3jH8Wpe/zxwY9opIqFoBBHuEgv2wWOWgJxzbJ9YiWeKEFPZdSTdM1Vf12paDRKrbmBFrNw/WxOhDCzkcEkCsUxqQDHul0oDthvz+780Lu/Zd2r7pigwtnRT6PBd7p+QSLiHOhHjw110oGh7RtCxyh8rXiXhwoJLmQYwAvPOh/QWHlCFUdyvybjU8LLgZtYxanR/qhPAcSFm0N2GbUkg8AX++L1hrWeUIYAYWy0DrsvPcGwsg+e4jKeyEHfRQli06Z0y+X/bltYYsEHhYYpl7eK1eXC8/7N6DYgXSPO0= 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: > -----Original Message----- > From: SeongJae Park > Sent: Tuesday, March 19, 2024 10:51 AM > To: Prasad, Aravinda > Cc: damon@lists.linux.dev; linux-mm@kvack.org; sj@kernel.org; linux- > kernel@vger.kernel.org; s2322819@ed.ac.uk; Kumar, Sandeep4 > ; Huang, Ying ; Hansen, > Dave ; Williams, Dan J ; > Subramoney, Sreenivas ; Kervinen, Antti > ; Kanevskiy, Alexander > > Subject: Re: [PATCH v2 0/3] mm/damon: Profiling enhancements for DAMON >=20 > Hi Aravinda, >=20 >=20 > Thank you for posting this new revision! >=20 > I remember I told you that I don't see a high level significant problems = on on the > reply to the previous revision of this patch[1], but I show a concern now= . > Sorry for not raising this earlier, but let me explain my humble concerns= before > being even more late. Please find my comments below: >=20 > On Mon, 18 Mar 2024 18:58:45 +0530 Aravinda Prasad > wrote: >=20 > > DAMON randomly samples one or more pages in every region and tracks > > accesses to them using the ACCESSED bit in PTE (or PMD for 2MB pages). > > When the region size is large (e.g., several GBs), which is common for > > large footprint applications, detecting whether the region is accessed > > or not completely depends on whether the pages that are actively > > accessed in the region are picked during random sampling. > > If such pages are not picked for sampling, DAMON fails to identify the > > region as accessed. However, increasing the sampling rate or > > increasing the number of regions increases CPU overheads of kdamond. >=20 > DAMON uses sampling because it considers a region as accessed if a portio= n of > the region that big enough to be detected via sampling is all accessed. = If a region > is having some pages that really accessed but the proportion is too small= to be > found via sampling, I think DAMON could say the overall access to the reg= ion is > only modest and could even be ignored. In my humble opinion, this fits w= ith the > definition of DAMON region: A memory address range that constructed with > pages having similar access frequency. Agree that DAMON considers a region as accessed if a good portion of the re= gion is accessed. But few points I would like to discuss: For large regions (say 10GB, that has 2,621,440 4K pages), sampling at PTE = level will not cover a good portion of the region. For example, default 5ms sampl= ing and 100ms aggregation samples only 20 4K pages in an aggregation interval.= =20 Increasing sampling to 1 ms and aggregation to 1 second can only cover=20 1000 4K pages, but results in higher CPU overheads due to frequent sampling= .=20 Even increasing the aggregation interval to 60 seconds but sampling at 5ms = can only cover 12000 samples, but region splitting and merging happens once in 60 seconds. In addition, this worsens when region sizes are say 100GB+. We observe that sampling at PTE level does not help for large regions as more samples are are required. So, decreasing/increasing the sampling or aggressions interva= ls proportional to the region size is not practical as all regions are of not = equal size, we can have 100GB regions as well as many small regions (e.g., 16KB to 1MB). So tuning sampling rate and aggregation interval did not help for large regions. It can also be observed that large regions cannot be avoided. Large regions are created by merging adjacent smaller regions or at the beginning of profiling (depending on min regions parameter which defaults to 10).=20 Increasing min region reduces the size of regions but increases kdamond overheads, hence, not preferable. So, sampling at PTE level cannot precisely detect accesses to large regions resulting in inaccuracies, even though it works for small regions.=20 >From our experiments, we found that with 10% hot data in a large region (80+GB regions in a 1TB+ footprint application), DAMON was not able to detect a single access to that region in 95+% cases with different sample and aggregation interval combinations. But DAMON works good for applications with footprint <50GB where regions are typically small. Now consider the scenario with the proposed enhancement. With a 100GB region, if we sample a PUD entry that covers 1GB address space, then the default 5ms sampling and 100ms aggregation samples 20 PUD entries that is 20 GB portion of the region. This gives a good estimate of the portion of the region that is accessed. But the downside is that as PUD accessed bit is set even if a small set of pages are accesse= d under its subtree this can report more access as real as you noted. But such large regions are split into two in the next aggregation interval.= =20 As the splitting of the regions continues, in next few aggregation interval= s many smaller regions are formed. Once smaller regions are formed, the proposed enhancement cannot pick higher levels of the page table tree and behaves as good as default DAMON. So, with the proposed enhancement, larger regions are quickly split into smaller regions if they have only small set of pages accessed. To avoid misinterpreting region access count, I feel that the "age" of the region is of real help and should be considered by both DAMON and the proposed enhancement. If the age of a region is small (<10) then that region should not be considered stable and hence should not be considered for any memory tiering decisions. For regions with age,=20 say >10, can be considered as stable as they reflect the actual access frequency. >=20 > > > > This patch proposes profiling different levels of the > > application\u2019s page table tree to detect whether a region is > > accessed or not. This patch set is based on the observation that, when > > the accessed bit for a page is set, the accessed bits at the higher > > levels of the page table tree (PMD/PUD/PGD) corresponding to the path > > of the page table walk are also set. Hence, it is efficient to check > > the accessed bits at the higher levels of the page table tree to > > detect whether a region is accessed or not. For example, if the access > > bit for a PUD entry is set, then one or more pages in the 1GB PUD > > subtree is accessed as each PUD entry covers 1GB mapping. Hence, > > instead of sampling thousands of 4K/2M pages to detect accesses in a > > large region, sampling at the higher level of page table tree is faster= and > efficient. >=20 > Due to the above reason, I concern this could result in making DAMON moni= toring > results be inaccurately biased to report more than real accesses. DAMON, even without the proposed enhancement, can result in inaccuracies for large regions, (see examples above). >=20 > > > > This patch set is based on 6.8-rc5 kernel (commit: f48159f8, > > mm-unstable > > tree) > > > > Changes since v1 [1] > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > - Added support for 5-level page table tree > > - Split the patch to mm infrastructure changes and DAMON enhancements > > - Code changes as per comments on v1 > > - Added kerneldoc comments > > > > [1] https://lkml.org/lkml/2023/12/15/272 > > > > Evaluation: > > > > - MASIM benchmark with 1GB, 10GB, 100GB footprint with 10% hot data > > and 5TB with 10GB hot data. > > - DAMON: 5ms sampling, 200ms aggregation interval. Rest all > > parameters set to default value. > > - DAMON+PTP: Page table profiling applied to DAMON with the above > > parameters. > > > > Profiling efficiency in detecting hot data: > > > > Footprint 1GB 10GB 100GB 5TB > > --------------------------------------------- > > DAMON >90% <50% ~0% 0% > > DAMON+PTP >90% >90% >90% >90% >=20 > Sampling interval is the time interval that assumed to be large enough fo= r the > workload to make meaningful amount of accesses within the interval. Henc= e, > meaningful amount of sampling interval depends on the workload's characte= ristic > and system's memory bandwidth. >=20 > Here, the size of the hot memory region is about 100MB, 1GB, 10GB, and 10= GB > for the four cases, respectively. And you set the sampling interval as 5= ms. Let's > assume the system can access, say, 50 GB per second, and hence it could b= e able > to access only up to 250 MB per 5ms. So, in case of 1GB and footprint, a= ll hot > memory region would be accessed while DAMON is waiting for next sampling > interval. Hence, DAMON would be able to see most accesses via sampling. = But > for 100GB footprint case, only 250MB / 10GB =3D about 2.5% of the hot mem= ory > region would be accessed between the sampling interval. DAMON cannot see > whole accesses, and hence the precision could be low. >=20 > I don't know exact memory bandwith of the system, but to detect the 10 GB= hot > region with 5ms sampling interval, the system should be able to access 2G= B > memory per millisecond, or about 2TB memory per second. I think systems = of > such memory bandwidth is not that common. >=20 > I show you also explored a configuration setting the aggregation interval= higher. > But because each sampling checks only access between the sampling interva= l, > that might not help in this setup. I'm wondering if you also explored in= creasing > sampling interval. > What we have observed that many real-world benchmarks we experimented with do not saturate the memory bandwidth. We also experimented with masim microbenchmark to understand the impact on memory access rate (we inserted delay between memory access operations in do_rnd_ro() and other functions). We see decrease in the precision as access intensity is reduced. We have experimented with different sampling and aggregation intervals, but that did not help much in improving precision.=20 So, what I think is it that most of the cases the precision depends on the = page (hot or cold) that is randomly picked for sampling than the sampling rate. = Most of the time only cold 4K pages are picked in a large region as they typical= ly account for 90% of the pages in the region and hence DAMON does not detect any accesses at all. By profiling higher levels of the page table tr= ee this can be improved. =20 > Sorry again for finding this concern not early enough. But I think we ma= y need to > discuss about this first. Absolutely no problem. Please let me know your thoughts. Regards, Aravinda >=20 > [1] https://lkml.kernel.org/r/20231215201159.73845-1-sj@kernel.org >=20 >=20 > Thanks, > SJ >=20 >=20 > > > > CPU overheads (in billion cycles) for kdamond: > > > > Footprint 1GB 10GB 100GB 5TB > > --------------------------------------------- > > DAMON 1.15 19.53 3.52 9.55 > > DAMON+PTP 0.83 3.20 1.27 2.55 > > > > A detailed explanation and evaluation can be found in the arXiv paper: > > https://arxiv.org/pdf/2311.10275.pdf > > > > > > Aravinda Prasad (3): > > mm/damon: mm infrastructure support > > mm/damon: profiling enhancement > > mm/damon: documentation updates > > > > Documentation/mm/damon/design.rst | 42 ++++++ > > arch/x86/include/asm/pgtable.h | 20 +++ > > arch/x86/mm/pgtable.c | 28 +++- > > include/linux/mmu_notifier.h | 36 +++++ > > include/linux/pgtable.h | 79 ++++++++++ > > mm/damon/vaddr.c | 233 ++++++++++++++++++++++++++++-- > > 6 files changed, 424 insertions(+), 14 deletions(-) > > > > -- > > 2.21.3