[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
On 05/26/2011 09:15 PM, Ingo Molnar wrote:
> * Avi Kivity<> wrote:
> > On 05/26/2011 02:38 PM, Ingo Molnar wrote:
> > >* Avi Kivity<> wrote:
> > >
> > >> > The biggest amount of RAM is the guest RAM image - but if that is
> > >> > mmap(SHARED) and mapped using hugepages then the pte overhead
> > >> > from a process model is largely mitigated.
> > >>
> > >> That doesn't work with memory hotplug.
> > >
> > > Why not, if we do the sensible thing and restrict the size
> > > granularity and alignment of plugged/unplugged memory regions to
> > > 2MB?
> >
> > Once forked, you cannot have new shared anonymous memory, can you?
> We can have named shared memory.

But then the benefit of transparent huge pages goes away.

Of course, if some is working on extending transparent hugepages, the
problem is solved. I know there is interest in this.

> Incidentally i suggested this to Pekka just yesterday: i think we
> should consider guest RAM images to be named files on the local
> filesystem (prefixed with the disk image's name or so, for easy
> identification), this will help with debugging and with swapping as
> well. (This way guest RAM wont eat up regular anonymous swap space -
> it will be swapped to the filesystem.)

Qemu supports this via -mem-path. The motivation was supporting
hugetlbfs, before THP. I can't say it was useful for debugging (but
then qemu has a built in memory inspector and debugger, and supports
attaching gdb to the guest).

> As a sidenote, live migration might also become possible this way: in
> theory we could freeze a guest to its RAM image - which can then be
> copied (together with the disk image) to another box as files and
> restarted there, with some some hw configuration state dumped to a
> header portion of that RAM image as well. (outside of the RAM area)

Live migration involves the guest running in parallel with its memory
being copied over. Even a 1GB guest will take 10s over 1GbE; any
reasonably sized guest will take forever.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

 \ /
  Last update: 2011-05-26 20:25    [W:0.091 / U:66.592 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site