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?
> > >
> >
>
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-
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
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
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
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
x
JFYI: today klive recorded this /proc/version:
Linux version 2.6.15-deb-reiser4 (2.6.15-deb-reiser4-10.00.Custom) ([EMAIL
PROTECTED]) (gcc-Version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)) #1
PREEMPT Wed Jan 25 17:56:04 CET 2006
This generated a new branch called 2.6.15-deb-reiser4-10.00.C
On Sun, Jan 08, 2006 at 08:48:20AM +0100, Sven Luther wrote:
> You could simply add the two distro-specific information, the full package
> name (2.6.14-2-amd64-k8) and the distro version number (2.6.14-7). I guess
> in additional often-intrusive patches, and will probably use a meaningful
> name.
On Sun, Jan 08, 2006 at 08:31:50AM +0100, Sven Luther wrote:
> You are not interested in recordying the debian abi number, or the flavour as
> a subset of the architecture used ? This seems like interesting info.
KLive wasn't originally designed to track distro packages, but mainline
or/and self-b
On Sun, Jan 08, 2006 at 08:04:33AM +0100, Sven Luther wrote:
> -1 was both the abi number and the debian revision. I guess you need to fix
> your script again :)
The client sends a plain /proc/version, so fixing this is very easy to
fix this on the server side.
> And none of those is really a sub
On Wed, Sep 14, 2005 at 05:02:18PM +0200, Sven Luther wrote:
> On Wed, Sep 14, 2005 at 04:46:04PM +0200, Andrea Arcangeli wrote:
> > On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote:
> > > On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote:
> > >
On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote:
> On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote:
> > On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote:
> > > Not a good idea. Why clutter the namespace of versions in order to adapt
On Sun, Sep 11, 2005 at 06:10:47PM +0200, Sven Luther wrote:
> Nope,; it works for debian packages. But you can match that to kernels.
not quite, you never know what kernel the system is running if you don't
call uname -r sorry. Note that klive is written for _mainline_ kernels,
see the homepage (
On Sun, Sep 11, 2005 at 07:35:02AM +0200, Sven Luther wrote:
> and report data ? If so, you may look into the popularity context package ?
Does that work for all distro out there? Could you post the url of
the equivalent of a klive.cpushare.com chart so we can compare? (google
pointed me to the pa
On Sat, Sep 10, 2005 at 09:42:17PM +0200, Sven Luther wrote:
> On Sat, Sep 10, 2005 at 08:02:38PM +0200, Sven Luther wrote:
> > On Sat, Sep 10, 2005 at 05:57:12PM +0200, Andrea Arcangeli wrote:
> > > On Sat, Sep 10, 2005 at 05:33:29PM +0200, Sven Luther wrote:
> > >
On Sat, Sep 10, 2005 at 05:35:56PM -0400, Andres Salomon wrote:
> Quite honestly, I don't think we deviate enough from the mainline kernels
> enough to warrant such a thing. The main patches we include are the stable
> kernel patches, misc fixes backported from linus' git repo, architecture
> patc
On Sat, Sep 10, 2005 at 05:33:29PM +0200, Sven Luther wrote:
> Sure, i am not stupid, i perfectly noticed that, now my question is why do you
> want to know that ?
That's for the klive project, I added two links in the first email just
check it again.
> Sure, it is a debian system, running a debi
On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote:
> Not a good idea. Why clutter the namespace of versions in order to adapt to
> non-debian needs. ? What is it you intent to do anyway ?
My intent is to be able to tell the "branch" of the kernel based on
`uname -r` (per subject). So if
Hello everyone,
I'm trying to detect a debian kernel from uname -r.
My suggestion would be to add a "-debian" at the end of the localversion
of kernels _patched_/modified by debian, and to leave the localversion
completely _empty_ (or an unchanged localversion compared to the
mainline defconfig)
20 matches
Mail list logo
