From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CE597E0E8 for ; Mon, 25 May 2026 02:19:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779675559; cv=none; b=ekRMXC2s1ehh0OpA0dF8iGT3tDnx9HcCPJneaDj4yu/ej85jLhPcw16PV2JjAGuqRrlzUeNj8T4Fvle3YD0XCAZ6jM0vv+ZFw8ZquSqmsYfcA6/8Tbtb2E3C/Zxp2oo3iJ6rXWxztVnzMJ4zVyoBOrNB2LJHo7P0vF0qWVjH8fs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779675559; c=relaxed/simple; bh=3Khw57xULA+G+f2y0+ZFi/5dDHu6BtWf7fq4HHz9jg4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=uonRLrtviR7o2LcZqnxMLRpbKSSJGHZfsapgFoRX5K88ZfjmvI90Vqp8IbqRMTS7V4qXKOr3oBu63kedYQT3KnYV+ollAl3ToJ5RSGoXAsig3Wf3yIAc58+xgFS+s80h9n+G4LqykiLdroPyXjhkc894hCUCW4gTNTaLmvyWiSU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=AQg2WzeR; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="AQg2WzeR" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2b46da8c48eso695ad.1 for ; Sun, 24 May 2026 19:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779675557; x=1780280357; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=ukB3uISQ810v40qB5GIvSZXVjcssnMcVF1JeENXejIQ=; b=AQg2WzeRYpGqTW5/IC10JTYxnV1/0lUPikAmSr192gtbYoysyTIfosoWG6up/PR7Z9 Wj0wj5Ccj8t6LZ71EO/xtYhlSZeVQx9mZvWLehSWg9Nu59j0mUVg40hhyL90SjmXJpbI shcmITyXFVQoJgUh9/Gh4zNu5wBiCezYQe7w15atjWDJTg/1OMUiuURr9L/MaVnbfsr7 9yb6d/znoc3YDgw8ykUA6G8xSDumFOeK0onIgNCAH0UMXIc7EMNOSwDbdG56kwzISwrs /7lQDUDi/dnxiBsvg/WYdFjCxJcGWYZGa9gMLjE3sPJdJh0K4x2nof4z3q4OlMGWOHz/ QoKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779675557; x=1780280357; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ukB3uISQ810v40qB5GIvSZXVjcssnMcVF1JeENXejIQ=; b=U2DSWBh9Ki9gUFEOAI1kpxoVezs7hzHc97IEWDTDsxnkJ8r6sKCPzptiI4ycQZyqtZ nybir50Fz5D4kC+WG8o91n5/thX7+ZxkFLlQN+Rtc0bbsJ1INorpI9talXpZj24mV9Tm imrBtcHQL48hE1fLOCXA0sOHzFNe7abbimIKY2QD97cQavEo+4n+2gBlnvygxRE0AGNP 4IQQNE2WkUpE+x1VrMVDca521ra31F3uoS/RneZs6BOa21rbPaBtH6PENHOHsyGtq/+C fXFnajCBQybEgJLINN00CnAoXqOdLJ8A9d7g4oxExf7II7IM5bjlIv5JOM0VOqrg/s/w IyAg== X-Forwarded-Encrypted: i=1; AFNElJ9RHtgJRSV852AtQcUiiq8m+SDO3vTLBGcTg+38wZTGmfoYujSljSrOkFadlZL8P+A9SeAuYpTvHSiOzXw=@vger.kernel.org X-Gm-Message-State: AOJu0YyjsTAJjZH9Tr8vA4KmHURnpGDzj92CdMCdOrW8Sc0axr8HlwNU kxhG7AiqKCWCnGcRoC78/PEnWPKq518sXKBdcNG3EaSQjiIEvAg7NUusMOSrgxMa2g== X-Gm-Gg: Acq92OEJC+1PmYDaGVFv1UBEaZXk3xdptnHWO7R8CzBJ6Tr2np97q0Jn59nGoXYzoSs EQ7B+i7+CkvITDWjBd14+fnfgK/vAMLgcrI+jamyn/SvQ3ZXVHR5KPKFHy20CwANfkYQ3yYYFFe lpW6GQhd7DTF2cmCS3f795wE00X0jJuTWSsN0ZX9Tt4HqW7f7jg+kQzpn3nm2Mrr6R/Bo3Ki639 byR0PKVxx4nKykZS4FeykCbeS54NFfuAFosMbatcQbrwnyoKFCZRALN6oju14KbAUElFwnIx/Jd 8J8wpdS4bXSUFaGJKXoUkBfvK8VfP8r+QMktgB3DKs2exw+a0NENE0r4sgwh/VyeG6MK6RyrEm/ OKVFY9/tkboJJqukTKBJRUIUTZwHgkFktyUE0umMxx1R+mBAf6UvuTQ78IwomE9zjYZY3ATg0ej /CdE0LNPJlz3nkbNS3jKpvLMSnXyt4xXf4MQB8ZwPVdXbZySEabXrZVQOUKzMiPl+JOwPK1uoCu gPXqzpTS2EzvCUnv8kGoSjNLUtnBZjN2qHW0P7LrUYUIhoJNXckzhQzykA63oHSapmOQtdBwWY= X-Received: by 2002:a17:903:37c5:b0:2bd:6dad:3dfd with SMTP id d9443c01a7336-2bec11df2e2mr2126205ad.27.1779675556850; Sun, 24 May 2026 19:19:16 -0700 (PDT) Received: from [2a00:79e0:2eb0:8:6235:ad35:aed6:8a48] ([2a00:79e0:2eb0:8:6235:ad35:aed6:8a48]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb56bc46esm83987925ad.25.2026.05.24.19.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 May 2026 19:19:16 -0700 (PDT) Date: Sun, 24 May 2026 19:19:15 -0700 (PDT) From: David Rientjes To: "Garg, Shivank" cc: "David Hildenbrand (Arm)" , Andrew Morton , kinseyho@google.com, weixugc@google.com, ljs@kernel.org, "Liam R. Howlett" , vbabka@kernel.org, Matthew Wilcox , rppt@kernel.org, surenb@google.com, mhocko@suse.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, Davidlohr Bueso , Jonathan Cameron , rkodsara@amd.com, vkoul@kernel.org, bharata@amd.com, sj@kernel.org, xuezhengchu@huawei.com, yiannis@zptcorp.com, dave.hansen@intel.com, hannes@cmpxchg.org, jhubbard@nvidia.com, peterx@redhat.com, riel@surriel.com, shakeel.butt@linux.dev, stalexan@redhat.com, tj@kernel.org, nifan.cxl@gmail.com, jic23@kernel.org, aneesh.kumar@kernel.org, nathan.lynch@amd.com, Frank.li@nxp.com, djbw@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 5/7] mm/migrate: add copy offload registration infrastructure In-Reply-To: Message-ID: <468db563-73b0-3f77-cf42-bb24f744c7d1@google.com> References: <20260428155043.39251-2-shivankg@amd.com> <20260428155043.39251-12-shivankg@amd.com> <9145ae5b-a33e-4092-8cb5-efa18ae61287@kernel.org> <70ee3800-0469-4c3d-8a1c-bb6594c64f42@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Received a bounce for Jonathan, so adding in his other email address. On Sun, 24 May 2026, David Rientjes wrote: > On Wed, 20 May 2026, Garg, Shivank wrote: > > > >> +static bool migrate_offload_do_batch(int reason) > > >> +{ > > >> + if (!static_branch_unlikely(&migrate_offload_enabled)) > > >> + return false; > > >> + > > >> + switch (reason) { > > >> + case MR_COMPACTION: > > >> + case MR_SYSCALL: > > >> + case MR_DEMOTION: > > >> + case MR_NUMA_MISPLACED: > > >> + return true; > > >> + default: > > >> + return false; > > > > > > > > > What's the exact reason we don't do this for hotunplug etc? IOW, why do we make > > > this depend on a reason? > > > > Reason-based filtering could be a requirement for some users who want only specific > > use cases to go through DMA offload. > > > > +1, I think this makes a lot of sense; not all DMA offloads are created > equally and we may prefer to unburden them from being contended by > migrations that they are not intending to accelerate. > > > For the RFC, I introduced a placeholder to enable further discussion on which use cases > > should allow migration offload and whether offload users actually need this control? > > > > Your other point also makes sense: "If someone migrates a handful of folios, latency is > > likely more important (and batching less beneficial)." > > Based on this, we could either fully rely on batch size. I'll think more about this. > > > > There are, or will be, some offloads that must be used for certain types > of page migrations, like Confidential Computing. That's for functional > reasons, not a heuristic. > > We want to use certain hardware assists solely for promotion and demotion > of memory for tiering. We certainly wouldn't want those hardware assists > to be inundated by users doing tons of move_pages(2) on their own or by > best effort memory compaction in the kernel. > > I think the use cases should be configurable by the user if at all > possible so we can control what has access to being offloaded. These are > often shared system resources and can be contended like any other > resource, so configuring which migrations can use them vs not use them > seems important. >