Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering

[Avi Kivity]

On 05/26/2011 09:15 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@xxxxxxxxxx>  wrote:
>
> >  On 05/26/2011 02:38 PM, Ingo Molnar wrote:
> >  >* Avi Kivity<avi@xxxxxxxxxx>   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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/