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:46:44 -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> <20150520141538 dot GV17573 at brightrain dot aerifal dot cx>
On Wed, May 20, 2015 at 10:15:38AM -0400, dalias@libc.org wrote:
> 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.
And the important one I forgot:
3. You need the virtual-to-physical mapping to remain fixed because
you're doing some sort of low-level hardware access (e.g. DMA, but
AFAIK modern systems have MMU for that anyway).
Rich