[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131206173843.GD3080@sgi.com>
Date: Fri, 6 Dec 2013 11:38:43 -0600
From: Alex Thorlton <athorlton@....com>
To: Mel Gorman <mgorman@...e.de>, t@....com
Cc: Rik van Riel <riel@...hat.com>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, hhuang@...hat.com
Subject: Re: [PATCH 14/15] mm: numa: Flush TLB if NUMA hinting faults race
with PTE scan update
On Fri, Dec 06, 2013 at 09:24:00AM +0000, Mel Gorman wrote:
> Good. So far I have not been seeing any problems with it at least.
I went through and tested all the different iterations of this patchset
last night, and have hit a few problems, but I *think* this has solved
the segfault problem. I'm now hitting some rcu_sched stalls when
running my tests.
Initially things were getting hung up on a lock in change_huge_pmd, so
I applied Kirill's patches to split up the PTL, which did manage to ease
the contention on that lock, but, now it appears that I'm hitting stalls
somewhere else.
I'll play around with this a bit tonight/tomorrow and see if I can track
down exactly where things are getting stuck. Unfortunately, on these
large systems, when we hit a stall, the system often completely locks up
before the NMI backtrace can complete on all cpus, so, as of right now,
I've not been able to get a backtrace for the cpu that's initially
causing the stall. I'm going to see if I can slim down the code for the
stall detection to just give the backtrace for the cpu that's initially
stalling out. In the meantime, let me know if you guys have any ideas
that could keep things moving.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists