AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
To: Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: "Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	"airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking
Date: Mon, 13 May 2019 20:31:49 +0000	[thread overview]
Message-ID: <af7bdc84-12d5-0e6b-c8cd-469bc8be5667@amd.com> (raw)
In-Reply-To: <20190513194925.GA31365-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[Fixed Alex's email address, sorry for getting it wrong first]

On 2019-05-13 3:49 p.m., Jerome Glisse wrote:
> [CAUTION: External Email]
>
> Andrew can we get this 2 fixes line up for 5.2 ?
>
> On Mon, May 13, 2019 at 07:36:44PM +0000, Kuehling, Felix wrote:
>> Hi Jerome,
>>
>> Do you want me to push the patches to your branch? Or are you going to
>> apply them yourself?
>>
>> Is your hmm-5.2-v3 branch going to make it into Linux 5.2? If so, do you
>> know when? I'd like to coordinate with Dave Airlie so that we can also
>> get that update into a drm-next branch soon.
>>
>> I see that Linus merged Dave's pull request for Linux 5.2, which
>> includes the first changes in amdgpu using HMM. They're currently broken
>> without these two patches.
> HMM patch do not go through any git branch they go through the mmotm
> collection. So it is not something you can easily coordinate with drm
> branch.
>
> By broken i expect you mean that if numabalance happens it breaks ?
> Or it might sleep when you are not expecting it too ?

Without the NUMA fix we'd end up using an outdated physical address in 
the GPU page table. The problem was caught by a test that got incorrect 
computation results using OpenCL on a NUMA system.

Without the FAULT_FLAG_ALLOW_RETRY patch, there can be kernel oopses due 
to incorrect locking/unlocking of mmap_sem. It breaks the promise that 
hmm_range_fault should not unlock the mmap_sem if block==true. It takes 
some memory pressure to trigger this.

Regards,
   Felix


>
> Cheers,
> Jérôme
>
>> Thanks,
>>     Felix
>>
>> On 2019-05-10 4:14 p.m., Jerome Glisse wrote:
>>> [CAUTION: External Email]
>>>
>>> On Fri, May 10, 2019 at 07:53:24PM +0000, Kuehling, Felix wrote:
>>>> Don't set this flag by default in hmm_vma_do_fault. It is set
>>>> conditionally just a few lines below. Setting it unconditionally
>>>> can lead to handle_mm_fault doing a non-blocking fault, returning
>>>> -EBUSY and unlocking mmap_sem unexpectedly.
>>>>
>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
>>>
>>>> ---
>>>>    mm/hmm.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/mm/hmm.c b/mm/hmm.c
>>>> index b65c27d5c119..3c4f1d62202f 100644
>>>> --- a/mm/hmm.c
>>>> +++ b/mm/hmm.c
>>>> @@ -339,7 +339,7 @@ struct hmm_vma_walk {
>>>>    static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
>>>>                             bool write_fault, uint64_t *pfn)
>>>>    {
>>>> -     unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_REMOTE;
>>>> +     unsigned int flags = FAULT_FLAG_REMOTE;
>>>>         struct hmm_vma_walk *hmm_vma_walk = walk->private;
>>>>         struct hmm_range *range = hmm_vma_walk->range;
>>>>         struct vm_area_struct *vma = walk->vma;
>>>> --
>>>> 2.17.1
>>>>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2019-05-13 20:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 19:53 [PATCH 0/2] Two bug-fixes for HMM Kuehling, Felix
     [not found] ` <20190510195258.9930-1-Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
2019-05-10 19:53   ` [PATCH 1/2] mm/hmm: support automatic NUMA balancing Kuehling, Felix
2019-05-10 20:13     ` Jerome Glisse
2019-05-13 21:27     ` Andrew Morton
     [not found]       ` <20190513142720.3334a98cbabaae67b4ffbb5a-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2019-05-13 22:37         ` Jerome Glisse
2019-05-14 21:14         ` Kuehling, Felix
2019-05-10 19:53   ` [PATCH 2/2] mm/hmm: Only set FAULT_FLAG_ALLOW_RETRY for non-blocking Kuehling, Felix
     [not found]     ` <20190510195258.9930-3-Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>
2019-05-10 20:14       ` Jerome Glisse
     [not found]         ` <20190510201403.GG4507-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-05-13 19:36           ` Kuehling, Felix
     [not found]             ` <65328381-aa0d-353d-68dc-81060e7cebdf-5C7GfCeVMHo@public.gmane.org>
2019-05-13 19:49               ` Jerome Glisse
     [not found]                 ` <20190513194925.GA31365-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-05-13 20:31                   ` Kuehling, Felix [this message]
2019-05-13 20:21             ` Deucher, Alexander
     [not found]               ` <BN6PR12MB1809F26E6AF74BE9F96DB22DF70F0-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-05-14 21:12                 ` Kuehling, Felix
2019-05-14 21:58                   ` Alex Deucher
2019-06-06 15:11   ` [PATCH 0/2] Two bug-fixes for HMM Jason Gunthorpe
     [not found]     ` <20190606151149.GA5506-uk2M96/98Pc@public.gmane.org>
2019-06-06 19:04       ` Kuehling, Felix
     [not found]         ` <1d309300-41d8-eb31-38c2-c6c9dd5c0ba8-5C7GfCeVMHo@public.gmane.org>
2019-06-06 19:20           ` Jason Gunthorpe
2019-06-06 19:16       ` Kuehling, Felix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af7bdc84-12d5-0e6b-c8cd-469bc8be5667@amd.com \
    --to=felix.kuehling-5c7gfcevmho@public.gmane.org \
    --cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox