Marcelo Tosatti wrote:
Sorry, still rejects horribly. What did you generate this against?
The kernel/ part seems unrelated.
This was merged through the kvm-devel branch (unless you dropped it).
Right, so that's why it rejected.
I even saw it in the log when I tried to find why it
On Thu, Feb 05, 2009 at 05:42:34PM +0200, Avi Kivity wrote:
> john cooper wrote:
>> Avi Kivity wrote:
>>> john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
th
john cooper wrote:
Avi Kivity wrote:
john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for refer
Avi Kivity wrote:
john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for reference.
Sorry for m
john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for reference.
Sorry for missing this (copyin
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for reference.
-john
john cooper wrote:
This patch from over a m
Avi Kivity wrote:
john cooper wrote:
This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle. Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.
What is the motivation for providing
john cooper wrote:
This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle. Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.
I must have missed it. Thanks for persisting.
In a nu
This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle. Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.
In a nutshell the intention here is to allow
preallocation of guest huge page
john cooper wrote:
Anthony Liguori wrote:
john cooper wrote:
As it currently exists alloc_hpage_mem() is tied to
the notion of huge page allocation as it will reference
gethugepagesize() irrespective of *mem_path. So even
in the case of tmpfs backed files, if the host kernel
has been configure
Anthony Liguori wrote:
john cooper wrote:
As it currently exists alloc_hpage_mem() is tied to
the notion of huge page allocation as it will reference
gethugepagesize() irrespective of *mem_path. So even
in the case of tmpfs backed files, if the host kernel
has been configured with CONFIG_HUGETL
john cooper wrote:
Anthony Liguori wrote:
+#include
I don't think this is necessary anymore. Depending on a Linux
headers breaks the QEMU build on other unices so it's a bad thing.
It is no longer required, but see below.
hpage is a misnomer too as we aren't actually dependent on hug
Anthony Liguori wrote:
+#include
I don't think this is necessary anymore. Depending on a Linux headers
breaks the QEMU build on other unices so it's a bad thing.
It is no longer required, but see below.
hpage is a misnomer too as we aren't actually dependent on huge pages (this
code
john cooper wrote:
Anthony Liguori wrote:
Marcelo Tosatti wrote:
This is Linux's behaviour for all filesystems. There is no error
checking on MAP_POPULATE's attempt to prefault pages.
I thought that mmap() will fail with hugetlbfs if enough large pages
can't be reserved?
This appears to
Anthony Liguori wrote:
Marcelo Tosatti wrote:
This is Linux's behaviour for all filesystems. There is no error
checking on MAP_POPULATE's attempt to prefault pages.
I thought that mmap() will fail with hugetlbfs if enough large pages
can't be reserved?
This appears to be the case for MAP
Marcelo Tosatti wrote:
On Tue, Jul 08, 2008 at 08:08:22PM -0500, Anthony Liguori wrote:
john cooper wrote:
I like it even less. MAP_POPULATE does not fault in physical
hpages to the map. Again this was a qemu-side interim bandaid.
Really? That would seem like a bug in hugetlb
On Tue, Jul 08, 2008 at 08:08:22PM -0500, Anthony Liguori wrote:
> john cooper wrote:
>> I like it even less. MAP_POPULATE does not fault in physical
>> hpages to the map. Again this was a qemu-side interim bandaid.
>
> Really? That would seem like a bug in hugetlbfs to me.
This is Linux's beha
john cooper wrote:
I like it even less. MAP_POPULATE does not fault in physical
hpages to the map. Again this was a qemu-side interim bandaid.
Really? That would seem like a bug in hugetlbfs to me.
+/* we failed to fault in hpage *a, fall back to conventional page
mapping
+ */
+int remap_
Anthony Liguori wrote:
+/* assertion checking
+ */
+#define ASSERT(c) if (!(c)) _assert(#c, __FILE__, __LINE__)
+
+static inline void _assert(char *text, char *file, int line) {
+fprintf(stderr, "ASSERTION FAILED: [%s] %s:%d\n", text, file, line);
+kill(getpid(), 12); /* dump c
john cooper wrote:
Attached is a patch to qemu which allows preallocation of huge
pages at startup time. Also in cases where sufficient huge
pages are not available, the user may request to selectively fall
back to 4K pages for those portions of phys_mem which couldn't be
backed by huge pages.
Attached is a patch to qemu which allows preallocation of huge
pages at startup time. Also in cases where sufficient huge
pages are not available, the user may request to selectively fall
back to 4K pages for those portions of phys_mem which couldn't be
backed by huge pages. This patch is relati
21 matches
Mail list logo
