Hi,
On Mon, Jun 11, 2012 at 03:27:38PM -0400, Konrad Rzeszutek Wilk wrote:
Nice. Andrew, any chane you could test this patch on the affected
Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
hypervisor or is it really only on Linode and Amazon EC2?
Originally, I
] that's caused by
commit 26c191788f18
Author: Andrea Arcangeli aarca...@redhat.com
Date: Tue May 29 15:06:49 2012 -0700
mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP
race condition
which was also included in Debian kernel 3.2.19-1.
[1
Hi,
On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote:
then the high part. Why that would trip the hypervisor
is not clear to me. Perhaps in the past it only read the
That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't
trip the hypervisor. That was tested
|= ((pmdval_t)*(tmp + 1)) 32;
}
+#endif
return (pmd_t) { ret };
}
But it's not worth the extra complexity. It looks cleaner if we deal
with good pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).
Andrea Arcangeli (1
to read the low part of the
pmdval atomically to declare the pmd as stable and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
On Thu, Apr 10, 2008 at 09:28:24AM +0200, Sven Luther wrote:
What about non-x86 architectures, well i guess ia64 and
powerpc/powerpc64 are the most interesting candidates.
It should be zero cost there too if it has been implemented
correctly. The only feature that initially generated a minimum
Hello,
The story about seccomp is that as long as there are users CPUShare
will support it because it's a more efficient and more secure
computing model.
About the seccomp overhead, that is zero. It adds zero overhead to the
fast path of the scheduler. It never added any overhead on x86-64. For
7 matches
Mail list logo
