On 01/06/2011 11:49 AM, Andrea Arcangeli wrote:
On Wed, Jan 05, 2011 at 03:27:37PM -0600, Michael Roth wrote:
On 01/05/2011 02:35 PM, Andrea Arcangeli wrote:
On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote:
Yah you're right, but I've seen several discussions about using mempath
fo
On Wed, Jan 05, 2011 at 03:27:37PM -0600, Michael Roth wrote:
> On 01/05/2011 02:35 PM, Andrea Arcangeli wrote:
> > On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote:
> >> Yah you're right, but I've seen several discussions about using mempath
> >> for tmpfs/ram-backed files for things l
On 01/05/2011 02:35 PM, Andrea Arcangeli wrote:
On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote:
Yah you're right, but I've seen several discussions about using mempath
for tmpfs/ram-backed files for things like numa/zram/etc so tend to
think of it as something potentially more than
On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote:
> Yah you're right, but I've seen several discussions about using mempath
> for tmpfs/ram-backed files for things like numa/zram/etc so tend to
> think of it as something potentially more than just a hook for
> hugetlbfs, which is bec
On 01/05/2011 01:54 PM, Andrea Arcangeli wrote:
Hello everyone,
On Wed, Jan 05, 2011 at 08:44:38PM +0100, Alexander Graf wrote:
On 05.01.2011, at 19:02, Michael Roth wrote:
On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
The bug is still there so I rediffed the old patch against current
cod
On Wed, Jan 05, 2011 at 09:00:45PM +0100, Alexander Graf wrote:
> Sure, not all combinations make sense. But "-mem
> size=1G,path=/dev/shm/vm1.ram,populate=on" would make sense, no? TPH
I was referring to Michael's suggestion, sure many options make sense
for mem-path too, in fact populate makes m
On 01/05/2011 02:00 PM, Alexander Graf wrote:
On 05.01.2011, at 20:54, Andrea Arcangeli wrote:
Hello everyone,
On Wed, Jan 05, 2011 at 08:44:38PM +0100, Alexander Graf wrote:
On 05.01.2011, at 19:02, Michael Roth wrote:
On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
On 01/05/2011 01:44 PM, Alexander Graf wrote:
On 05.01.2011, at 19:02, Michael Roth wrote:
On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
The bug is still there so I rediffed the old patch against current
code.
On a related topic: could somebody give me advice on how to implement
a
On 05.01.2011, at 20:54, Andrea Arcangeli wrote:
> Hello everyone,
>
> On Wed, Jan 05, 2011 at 08:44:38PM +0100, Alexander Graf wrote:
>>
>> On 05.01.2011, at 19:02, Michael Roth wrote:
>>
>>> On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
The bug is still there so I rediffed the old pat
Hello everyone,
On Wed, Jan 05, 2011 at 08:44:38PM +0100, Alexander Graf wrote:
>
> On 05.01.2011, at 19:02, Michael Roth wrote:
>
> > On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
> >> The bug is still there so I rediffed the old patch against current
> >> code.
> >>
> >> On a related topic:
On 05.01.2011, at 19:02, Michael Roth wrote:
> On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
>> The bug is still there so I rediffed the old patch against current
>> code.
>>
>> On a related topic: could somebody give me advice on how to implement
>> a command line (command line seems enough,
On 01/05/2011 09:10 AM, Andrea Arcangeli wrote:
The bug is still there so I rediffed the old patch against current
code.
On a related topic: could somebody give me advice on how to implement
a command line (command line seems enough, the other option would be
monitor command) to make the MADV_ME
The bug is still there so I rediffed the old patch against current
code.
On a related topic: could somebody give me advice on how to implement
a command line (command line seems enough, the other option would be
monitor command) to make the MADV_MERGEABLE conditional? I got KSM on
THP working fine
Am 15.09.2010 um 19:08 schrieb Andrea Arcangeli:
From: Andrea Arcangeli
All allocated guest physical memory shall be marked MADV_DONTFORK,
otherwise
fork will fail because of accounting issues preventing migration or
netdev_add
when the guest allocated more than half of host physical memo
On 15.09.2010, at 19:08, Andrea Arcangeli wrote:
> From: Andrea Arcangeli
>
> All allocated guest physical memory shall be marked MADV_DONTFORK, otherwise
> fork will fail because of accounting issues preventing migration or netdev_add
> when the guest allocated more than half of host physical
From: Andrea Arcangeli
All allocated guest physical memory shall be marked MADV_DONTFORK, otherwise
fork will fail because of accounting issues preventing migration or netdev_add
when the guest allocated more than half of host physical memory.
Signed-off-by: Andrea Arcangeli
---
diff --git a/e
16 matches
Mail list logo
