From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 A13C513B293 for ; Mon, 25 May 2026 02:16:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779675419; cv=none; b=nVn9fRabfTC/KLCAouqW5QGvvfovY8MJJ8pYtkoUAfG8IQUF7GiFiLnhg9lOx/iF6S3hgRfAE6Y3XKbDu9yRKRJI8JyRXvklHKyMGPPMxk73ADkrQjsRzOcFXTkaA50CxglGerw0qVXAkoLdexA33PNB7Uboiy48KwCkBdXnlxU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779675419; c=relaxed/simple; bh=faR2BEy8trbGd1oINrOJkXEoHIMnzV4QHXF727uUt+M=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=psIezwWWCREjuxTl3Ipml2VGZg1P6aa7SgQZEoz2+LdwNO3si3QO7II352U/oUmfP/cwyiH1zFMdv7tCFedUKQJ51ucR2OYGDPPsMCp9R4FWHrinu0jOWz7+MBNjEE4/113m9qLLcMuRpGwad85noFG8EJJC3I1Q/Ny5VeJRpHM= 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=mc738u1u; arc=none smtp.client-ip=209.85.214.177 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="mc738u1u" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2b2e8b95bdbso315ad.0 for ; Sun, 24 May 2026 19:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779675418; x=1780280218; 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=dfsAkAdU4PDOgxXu/2olDrWiHUvDAk/BhzLy0f6l/Ss=; b=mc738u1uOXHg76L/wciyxc3L5umYLdOWE+gmusiVwokWA7Eq4oRXRXxcWjAXhYodxm nL25dpks7+lzFTbn7C+m5u6N6P9Hy0RcUliHb6V0c7scMMttH8/iwzTS4obt0CJJJrIU RErHnDlO8qaaCo5q/zxm+nv2kAodXSGvkJHNRjvaLimIPO5+kWHLqn37OoS0/tsygHe8 EKhSKGDQWSXHZO4S0jbCyMQe3t42nAEKjvd1MW8W/rK+lyy9maSmENnDjj4T+Zi8lp1M RclkASqKLJ6NJKT1oTI5Vm3Iw3hpSbzgne5hf9/kluoiZfoE/UrDcKau6o2ZDE60hP7A LbhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779675418; x=1780280218; 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=dfsAkAdU4PDOgxXu/2olDrWiHUvDAk/BhzLy0f6l/Ss=; b=C+qPxPQuGXrs9yRfnY6sEOSrv+omr6y1pulvJ/6iYXXfpHX/qgwcPeBuuoTdvVY+gs 3BDrgcZOpWQPJ1ElGYsj2J6ZjDCSa8dpFn9sobJVFnBczfZ7+RVV7JrpbR4zwl1Ht7od hcdG+y3ZqMPEqa+2oxFqWd2psF5FPme615doSH6HA48lYqLpxVixdfOq/HQzMfsjFW0e VnB21BDqEBz2ii0n9NKLNevwjQFLcgGmga38qrVKN9NfBOgoLQIexmhknikiyjgmgMKn GfBqoNdG+bZ3yIK9ZvGJgaCVflvQ9QOrwGlzQxRJI4d9HXkXw37TEh13QtV1cqzINRbV ujTw== X-Forwarded-Encrypted: i=1; AFNElJ8zdHhdbUdQZw0ug/zz1jg5NUv7o61+v2E79lR5JmdUXNPKpRVErqJmTS7gPhVBySmj81fQUmkuefc8fNE=@vger.kernel.org X-Gm-Message-State: AOJu0Yxz8NvIw8Sfy8qWPlCEyMXP8AOLwcDDDYiCPfr279z5hMcgayXm b8CmWgoKDBeWbsM/qAX+XJn6lLHM2v59rIRecvULcFzaCnSt/EtMEdrSA7OUluwSeA== X-Gm-Gg: Acq92OGQcqRAPKKQWFjTvWn1cs5pJ3erWOA0l0o/vcsSK2rpo5Ydj5v7YtzAHLJLzKx 4QMvZ6r4qtTpp1wN0mlkLJqAeATsIqy7WrjFrmIWNJ2X6D/fDnNFvZlGKL0urM9js540tfyOZBn RdIzNvzlnhx0CZ6cgMe0BWO4qmVzN0GyA1Wi4Gnw/ucJahWNex4ckls6dAsUbWCMjBAp8DwVxsn fgkAvorozQyS1kzx9/9j5Q9p0isrhnaJaY+VmCKVzKEc9k2wv03UVNYMHfGJZFNv8E3/ltzUdYs N+X9eHbP2BgnkN44e4wsqHkuf8szEnaCse9SbUzMwfJzoI4v+8h4EGBWjsv7sFPmvlHNTl94+wp 407ka2X6SVp87/eUU0tHcZo/f7F6jKAqbNLWOOJH1Ry6sogh69lhT57EiOua93bNtVqP3fBY859 zcxdOftcvi55S0QOMLz2WRy5DK48KN1Qk3iJAFxjDnNQWAt7YqMrrhp16oS1oOB+yELkCOP33BF /sEmHSeEkRY2iMJwTqA+w1SVYsL2c6Hnn/Y30DoD9/8UCsbKZYckzrVCdoTt0eG X-Received: by 2002:a17:903:3c2b:b0:2bd:3c1b:3073 with SMTP id d9443c01a7336-2bebf41888cmr2832375ad.16.1779675417380; Sun, 24 May 2026 19:16:57 -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 98e67ed59e1d1-36a721c858csm8026039a91.11.2026.05.24.19.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 May 2026 19:16:56 -0700 (PDT) Date: Sun, 24 May 2026 19:16:55 -0700 (PDT) From: David Rientjes To: "Garg, Shivank" cc: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, kinseyho@google.com, weixugc@google.com, ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, willy@infradead.org, 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, dave@stgolabs.net, Jonathan.Cameron@huawei.com, 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: <70ee3800-0469-4c3d-8a1c-bb6594c64f42@amd.com> Message-ID: 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 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.