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 77D9AC7115B for ; Mon, 23 Jun 2025 14:08:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0230E6B00BE; Mon, 23 Jun 2025 10:08:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3D6F6B00C1; Mon, 23 Jun 2025 10:08:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E532F6B00C2; Mon, 23 Jun 2025 10:08:15 -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 CF2516B00BE for ; Mon, 23 Jun 2025 10:08:15 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 547F9103B1D for ; Mon, 23 Jun 2025 14:08:15 +0000 (UTC) X-FDA: 83586844950.25.2A71967 Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf14.hostedemail.com (Postfix) with ESMTP id 7483C10000A for ; Mon, 23 Jun 2025 14:08:13 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PAJAPcrD; spf=pass (imf14.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750687693; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EowSWZHgBam44vNn1dpUDGU5HPdMXeRQtrflhATFszk=; b=0vU5+QX3RME2c5b4AlduVC03vHR2zL+xm/56azZn6M1uBYChguVI2DN43j06yMQ3dYheB6 6/TuEQZA3eDYoRxBQfHFyT6JN2ImZ5xmFZyMMJ1UY4utzwh1ozfTeyXZRHWDYiZeGDVy9X DuM3EZzbvRUsQb1tufwr8vho8XLTYmM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PAJAPcrD; spf=pass (imf14.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750687693; a=rsa-sha256; cv=none; b=JuMbH4Yds/OeNwQC5fUrrxUXMc6wxRAVY0mJ0F48tJJ1Ua6RvJNm2Zff86sfiK38VWgo2v vtYoWF3SDAxve1kh8FNkLS7tRhxpYu6ePqyFQOIl/2uNn5woRbpzmvU7vGdwZBclstx9ap zTl238RLtkAm3oP/CVLKJvBYhTVmxAs= Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e7387d4a336so3154273276.2 for ; Mon, 23 Jun 2025 07:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750687692; x=1751292492; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EowSWZHgBam44vNn1dpUDGU5HPdMXeRQtrflhATFszk=; b=PAJAPcrDm4B5TUiZ/gMexj0E2js+nyBkPgkHRpWxEJhhnhyhlANmdIukWrMp2JP794 sbfedNBNhecwDx8NxFl4lXikfs4nA01bLZM/FEdzzfjkK1ZxPxOtkqHl3MQBqeuOeiOa coCXuAWAzz1IiIZa//qbL0B8qSte9syGLNftdJ1IXVXxjH1SXKOAKZb63YQL66eJYHOZ j/hRuoMWH5SLxLlUSOh9WtjkQwokos7MUhAVsmtMnvR4Tl6gMkFzgDP7C9qFcP7rybCg 5y+EPocFRA2oDlx5u5XpjiLx5V++hTEaWbs2F3O+PsuwZE4vGm/XIa4RoBut5j6su7ia hB9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750687692; x=1751292492; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EowSWZHgBam44vNn1dpUDGU5HPdMXeRQtrflhATFszk=; b=T5h9zG606Dr/GCC1hZcwomO4ydbPYPMA40rZgEdTTQaLLWV/92lyYue5OgC7zAvZNY t//qFJFoQQDCeoh+5zEi0qEGnyqlx63oEGLbXXxzI1eCflBWWDmv9QM2Bc9P/DtDFtuH gaUa/nVxKZIQjy+Cn7k3F7CARm7tVPwUi8Y1xE+LXLACJyJjhVAtXBSPiPVRJQX34LCG wgEGSzX9cfwHDokXZBunGgs6dMw/Rx0+clw+r76IxFPwqtCY+pwMc0l7JaSXZfFe5bUt Uen2QRuQw8US6+6dLourBmwDGAo8ZEOVNwuwWg8oQsDwAnRi9M5v8wg8/9njQFmxgstA Gwjw== X-Forwarded-Encrypted: i=1; AJvYcCW7UyGXZmdVPso3V+eqaUoLZ8qLRB3ALcgs1cloNs+8cY26PoOSqxtsW5miTf6sfM1vfPqEN+JtPA==@kvack.org X-Gm-Message-State: AOJu0YxUtnip6LRKcO+kGJpPvTsF+vk9pWJXjXpGRPB9wTeUVI8h6Hce FcbHxtlKhNjxQK/BJ4esiW52NTBziSwbSx02dcWfGlDS1qxYm07H438j X-Gm-Gg: ASbGncsFmQ9T4nxo2U6sknnXBuDJhcs69eGdgjzqs0zvDA0ktCeIq/nXNPGs6wvVj2A bx3vgXWCNe/uYu+HpgkwUvgO8aRbJAcsKKG4hvJaScoXaxGyVj3Mrt2YVvfQPFxDswxqnVx6TfQ dXsD5MPzbEWFQu/5kRjtMjv5uZUqlJSekPRy3ZXxWeiRvq78llujDT4ab6xqR7nWNi/gq5xu7qm aua14XbFritljNk71Dy8H5KHD3j8+1SgFAFdJLMgDj5Vxsz0kbfIlc5NjUs9Kx4WbcMFwfsQNjO p5J16hNpKXpmE2jtK4m1b08QPcDIhCRAJFqPuY2PFnqFgdf76yBmgdtILE6LTw== X-Google-Smtp-Source: AGHT+IHYE3nYS125xTmonu6rlnXOXYSJSgL5k5E0ktAjTh63MUDrmHzRWNjGR5ZWVHUoeEPNQJRVuw== X-Received: by 2002:a05:6902:72a:b0:e7d:cbd0:66a3 with SMTP id 3f1490d57ef6-e842bd078c9mr15228034276.35.1750687691448; Mon, 23 Jun 2025 07:08:11 -0700 (PDT) Received: from localhost ([2a03:2880:25ff:40::]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e85e70124e5sm341310276.11.2025.06.23.07.08.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jun 2025 07:08:10 -0700 (PDT) From: Joshua Hahn To: SeongJae Park Cc: Bijan Tabatabai , damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, david@redhat.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, bijantabatab@micron.com, venkataravis@micron.com, emirakhur@micron.com, ajayjoshi@micron.com, vtavarespetr@micron.com Subject: Re: [RFC PATCH v2 2/2] mm/damon/paddr: Allow multiple migrate targets Date: Mon, 23 Jun 2025 07:08:07 -0700 Message-ID: <20250623140808.2479244-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250621181127.36394-1-sj@kernel.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 7483C10000A X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 6kf1knjtgwirq538onc7hsdfo4jwz74x X-HE-Tag: 1750687693-782437 X-HE-Meta: U2FsdGVkX1+1aXAchJEkhm93gbQ8Kv5VnMemsCUube+xb5KEEVOiBGf0Nrat6bxJheLfD1k+Rn7OdelPu6kXi9RYMJfg/5yGeFJoH4o7yY6vtiw3sMyBXH0Wlk8ey50eZ65uLOVr+xiZ2CRBsaw7f0ycbbmCEVVRxePMepo1na1XsZbkA3ReHz7PHG86RlN2oarJx3kJOkXfA1reEc1NjHRwyugIc5AHXlRnodEJEBjUumHjw4QeTb8f1AquUJbbAxhPPuYe8qtWSLknv8KNnqub11yfo+OwhvZkewmeoP+r1BexFEVY9hPE4VTVmfUfc0ug111A80Ry5RozV0MNKqkQs4f7DyTDkyR/76l18ohkTECUXWijI7SpDCcpb4XrlYnms+tDdQ4UmU2+1bnYkVl/KUPq5GkcebxCWEWlLXOt5znQ5aD86gCwx6wLo8tpDw9kN7aBaQIePrB0qiPJM7pUn3iXY3CrnRvRm9MrNeYMAYROB/49uP3THpfz4MMC3Wn/wzHvnEGbMF1nmw1+KQal3y9xSizSvd6umGI/FpCA5Ybud7zN6u+2Sjlnmv/6y8i8jxbxICndfJweutzGlts+BlZVC5B+PYBZ/Ryd/p4kMVv1pLA3GZ8oafpYamkW1l/Ow3LhkxEEaLu4YAoKK2kX8OwtsXrPOT600dPxrRnrHBDpBnjHpfLfXLDMXoptSY/R34AA7DUR3XnDrv0eo6DNGaXTDjettRChQTfbkFOoPGe/JYmPuPLPBF6u9unZ/Nl0sKIwtBQjNccOHDWSmMdxGpCEW9yjyZcBMK/RIJqDFvylyJDJFntdFuFQQEkylhGBInF3scscWeC+L2EHqEk2ZEflCGMdDEcVRPid5MMOska1YS54qvL+LZu1KaZ032N9LydpCVGJquzl6vwbiGAbFJOqII8e9z4zCXJYLYAjE0MVz4HznUDho8TO8R63xHE+e/Lj+esJ46wX8Br Le2N62I7 afJsibzBIrWsKiGOKmnueUwXNrxsO7N2HU8GCdjjL7mHbwjureTzTtR9JM2w4VARZBAv+3ILDG7ENKJj8zoIyuC0Cm0TW3LRH3Bv/XlqtATr4I10ehS8WAgYdCT0JqMFptSmDMvpaTLlRaP1wQvkyjNpm8alGoh3MGiBNe2PMXLx6RQHb6wv9EPkCRBlD0r6YuoAyK3sWDwPCO7QiDWiZY2zSnFwy4KPPTHi1GIJDqH19lWXE6MnjR8wHOMX/98cNAl2u80MXgSxdGBviomi16PF3imVouHNVcAqvd0Xrl6vy5vgfT6d3YVLAleZ5EnJo7UQUFR6421P3un4xHyndStXytPWiIUdy4CySRORnQJByv9B5zSLGzo1qWrUfF3qfGiHjbVdihUd4PMLf5nJTbGLViBgFFSuCwHsIPAsdOTQRmxESb8rClyncGhI342UeSeknXcz/ogMllVrNKyLkN4J49MkHW4UkDm70qA+mJnGSzlDuJlOKVb0yLbh/XN6wdhDTBgZasVe1gIT8S24/HL9ILEPURgbyE91lXOz2XDu0/k1tjphxfFWfwelApL2nIFsfAY/Ly+5hcBnigV4s81b4+A== 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: On Sat, 21 Jun 2025 11:11:27 -0700 SeongJae Park wrote: > On Sat, 21 Jun 2025 11:02:15 -0700 SeongJae Park wrote: > > [...] > > I'd hence suggest to implement and use a simple weights handling mechanism > > here. It could be roud-robin way, like weighted interleaving, or probabilistic > > way, using damon_rand(). > > > > The round-robin way may be simpler in my opinion. For example, [...snip...] > Actually, probabilistic way may be not that complicated. Maybe we could to > below here. [...snip...] > But damon_rand() might be more expensive than the roud-robin way, and arguably > roud-robin way is what usrs who familiar with weighted interleaving may easily > expect and even prefer? I have no preferrence here. Hi SJ, If you have no preference here, I would like to add some thoughts : -) I think that code complexity aside, round-robin may be the better choice for a few reasons. Like you mentioned, I think it is what users might be used to, if they are coming from weighted interleave code. Also, I think a round-robin way will prevent worst-case scenarios where we get a long stretch of allocations on the "wrong" node (but maybe this isn't a big deal, since it is so unlikely). Finaly -- If we run workloads with mempolicy wet to weighted interleave *and* with the weights already set, then pages will be allocated in a round-robin fashion. I think it may be best to try and minimize migration costs by trying to keep these weights in-sync. That is, if we have a 2:1 ratio, we will have the following allocation: node0 | oo oo oo oo oo oo oo ... node1 | o o o o o o ... Using a probabilistic migration, it might change the pattern: node0 | oooo oo o ooo oo ... node1 | oo o o o o ... That is, the ratio might be preserved, but we may be doing unnecessary migrations, since a probabilistic allocation isn't aware of any underlying patterns. With a round-robin allocation, we have a 1/total_weight chance that there will be no additional migrations, depending on where the round-robin begins. I also want to note that weighted interleave auto-tuning is written to minimize total_weight. I'm wondering what you think about this. Perhaps there is a way to know where the "beginning" of round-robin should begin, so that we try to keep the allocation & migration pattern as in-sync as possible? I have a suspicion that I am way over-thinking this, and none of this really has a tangible impact on performance as well ;) Thank you as always SJ, have a great day!! Joshua > Thanks, > SJ > > [...] > Sent using hkml (https://github.com/sjp38/hackermail)