Re: [PATCH v17 00/12] migrate on fault for device pages

["Mika Penttilä" <mpenttil@redhat.com>]

On 11/13/26 02:27, Andrew Morton wrote:

> On Thu, 12 Nov 2026 19:01:58 +0200 Mika Penttilä <mpenttil@redhat.com> wrote:
>
>> On 11/12/26 18:47, Jason Gunthorpe wrote:
>>> On Thu, Nov 12, 2026 at 04:24:05PM +0000, Alexandru Elisei wrote:
>>>> Hi Mika,
>>>>
>>>> On Thu, Nov 12, 2026 at 04:00:09PM +0200, Mika Penttilä wrote:
>>>>> Hi Alexandru!
>>>>>
>>>>> On 11/12/26 13:56, Alexandru Elisei wrote:
>>>>>> Hi Mika,
>>>>>>
>>>>>> I want to help getting this series merged, and I've been familiarizing myself
>>>>>> with hmm and device migration, please bare with me if the questions I'm asking
>>>>>> are obvious or downright silly.
>>>>> Thanks for the interest and willing to help! I am preparing a v18 of the
>>>>> series and plan to post it early next week.
>>>> The series is big, and as far as I can tell the MM people are hard at work
>>>> reviewing bug fixes. It might be better to wait a while, to give people a
>>>> chance to have a look? I know that if I see a series being reposted often,
>>>> I am less inclined to review the patches since probably a new iteration
>>>> will be posted soon. But I can only speak for myself, you know best.
>>> It is at v17 and it is still getting high severity sashiko errors
>> v14 was first that sashiko managed to review. There was a regression in
>> last posting, but also false potsitives, and sashiko reports same issue
>> then 3-4 times, so the reality is not that bad. 
> Pining for the days when all we had to deal with was checkpatch.  

Yeah.. running sashiko locally now. Interesting enough, refactoring the
series (end result being the same) made most of the "high errors" disappear.


> Mika, afaict the entire patchset is a performance optimization, yet you
> say "I don't have a benchmark showing a gain".

No not a performance optimization as is, in the latest cover I explain it:

"The main goal of this patchset is to provide a new feature,
migrate efficiently on fault, and not directly improve performance
of current migrate_vma_setup() (which is now routed thru
hmm_range_fault()) callers."

The "efficiently" is wrong word, I should say "in one walk".  In the
beginning of the cover, I explain the benefits of having one walk. Also,
I think it is sensible to have one implementation for it in HMM, instead
of each driver trying to do something similar.

We don't currently have in kernel the capability to do migrate on fault
in one walk, so I can't show a performance gain with a simple apples to
apples test.

Also :

"the selftests show that there is at least no regression for
current migrate_vma_setup() callers."

So the test is to show there is no regression still for current callers
(X86-64), not to show if there would be gains.

>
> Recipients look at patchsets wondering "why should I spend time on
> this", especially in these times.  It's best to answer this question
> right there in the first sentence of the [0/N].  That means numbers,
> and the better they are, the more attention the patchset will get.
>
>>  Documentation/mm/hmm.rst               |   45 +
>>  drivers/gpu/drm/nouveau/nouveau_dmem.c |  402 ++++++++-
>>  drivers/gpu/drm/nouveau/nouveau_dmem.h |   12 +
>>  drivers/gpu/drm/nouveau/nouveau_svm.c  |  155 ++--
>>  drivers/gpu/drm/nouveau/nouveau_svm.h  |    5 +
>>  include/linux/hmm.h                    |   51 +-
>>  include/linux/migrate.h                |   59 +-
>>  lib/test_hmm.c                         |  174 +++-
>>  lib/test_hmm_uapi.h                    |   21 +-
>>  mm/Kconfig                             |    1 +
>>  mm/hmm.c                               | 1075 ++++++++++++++++++++++--
>>  mm/migrate_device.c                    |  618 +++-----------
>>  tools/testing/selftests/mm/hmm-tests.c |   56 ++
>>  13 files changed, 1984 insertions(+), 690 deletions(-)
> also, yikes!

Yeah, the nouveau made the numbers bigger - but we have a real user!

--Mika