[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxyx_wcsgYJC2GXcjEvMsTg=K=uy6A=xDJdWdvZsE1VHQ@mail.gmail.com>
Date: Tue, 16 Dec 2014 16:00:48 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mel Gorman <mgorman@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...capital.net>,
Steven Rostedt <rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Frederic Weisbecker <fweisbec@...il.com>,
Don Zickus <dzickus@...hat.com>, Dave Jones <davej@...hat.com>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: frequent lockups in 3.18rc4
On Tue, Dec 16, 2014 at 3:02 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> OK, should we just stick it in the x86 tree and see if anything
> explodes? ;-)
Gaah, I got confused about the patches.
And something did explode, it showed some Xen nasties. Xen has that
odd "we don't share PMD entries between MM's" thing going on, which
means that the vmalloc fault thing does actually have to occasionally
walk two levels rather than just copy the top level. I'm still not
sure why Xen doesn't share PMD's, since threads that shame the MM
clearly can share PMD's within Xen, but I gave up on it.
That said, making x86-64 use "read_cr3()" instead of
"current->active_mm" would at least make things a bit safer wrt NMI's
during the task switch, of course. So *some* 32/64-bit consolidation
should be done, but my patch went a bit too far for Xen.
Linus
--
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