[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170713201620.GB1979@redhat.com>
Date: Thu, 13 Jul 2017 16:16:20 -0400
From: Jerome Glisse <jglisse@...hat.com>
To: Evgeny Baskakov <ebaskakov@...dia.com>
Cc: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
John Hubbard <jhubbard@...dia.com>,
David Nellans <dnellans@...dia.com>,
Mark Hairgrove <mhairgrove@...dia.com>,
Sherry Cheung <SCheung@...dia.com>,
Subhash Gutti <sgutti@...dia.com>
Subject: Re: [HMM 12/15] mm/migrate: new memory migration helper for use with
device memory v4
On Tue, Jul 11, 2017 at 12:35:03PM -0700, Evgeny Baskakov wrote:
> On 7/11/17 11:49 AM, Jerome Glisse wrote:
>
> >
> > What are the symptoms ? The program just stop making any progress and you
> > trigger a sysrequest to dump current states of each threads ? In this
> > log i don't see migration_entry_wait() anymore but it seems to be waiting
> > on page lock so there might be 2 issues here.
> >
> > Jérôme
>
> That is correct, the program is not making any progress.
>
> The stack traces in the kernel log are produced by a "sysrq w" (blocked
> tasks) command.
>
I updated hmm-next with a patch that might fix some other issues but i am
still trying to get this dead lock you are seing. Does it happens quickly
with the test program ?
I can't see how it dead lock on the page lock bit. Going over and over all
code path we always unlock page once we are done or when we back off from
migration. So far i haven't been able to reproduce thought i haven't had
much time to test as other thing kept me busy. I should be back looking into
that tomorrow.
https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-next
Cheers,
Jérôme
Powered by blists - more mailing lists