This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "dalias at libc dot org" <dalias at libc dot org>
- To: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "fweimer at redhat dot com" <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 20 May 2015 10:15:38 -0400
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <5552104C dot 1020806 at redhat dot com> <20150512152207 dot GW17573 at brightrain dot aerifal dot cx> <1431513937 dot 2622 dot 24 dot camel at intel dot com> <20150513170809 dot GY17573 at brightrain dot aerifal dot cx> <555397D0 dot 70808 at redhat dot com> <20150515012433 dot GC17573 at brightrain dot aerifal dot cx> <1432130053 dot 17726 dot 6 dot camel at intel dot com>
On Wed, May 20, 2015 at 01:54:13PM +0000, Kinsella, Ray wrote:
>
> > I did a little bit of research and it appears that only lock-prefixed
> > instructions which can page fault are affected by this bug. So why not
> > just make the kernel enforce mlockall for all processes on affected
> > cpus?
>
> mlockall doesn't help in situations where a page is marked as CoW, you
> still get the page fault on write (i.e. lock cmpxchg -
> read/modify/write).
If this is true, it's a bug in the implementation of mlockall. The
whole point of memory locking is to prevent the need to allocate
memory at page fault time, which matters for multiple reasons,
including at least:
1. Real-time applications that can't accept the possible latency.
2. Reasons related to commit charge/overcommit/OOM-killer.
> > I'm not clear on whether the bug crashes the whole system or
> > just clobbers the user process state in an unrecoverable way, but if
> > it's the latter, only writable pages would need to be locked;
> > read-only pages could still be paged normally.
>
> It clobbers the process the process state in an unrecoverable way. The
> problem doesn't affect the Kernel, as the Kernel doesn't page fault.
In that case I think mlockall (with the above bug fixed) is a viable
kernel-side workaround.
Rich