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?
> > >
> >
>
te).
> [...]
> > Non-Xen boots proceed normally.
>
> Yeah, apparently[2] that's caused by
>
> commit 26c191788f18
> Author: Andrea Arcangeli
> Date: Tue May 29 15:06:49 2012 -0700
>
> mm: pmd_read_atomic: fix 32bit PAE pmd w
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
ret |= ((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_off
6 case, it is enough 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-
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
x
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
7 matches
Mail list logo
