lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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<avi@redhat.com> wrote:
    >
    > > On 05/26/2011 02:38 PM, Ingo Molnar wrote:
    > > >* Avi Kivity<avi@redhat.com> 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:4.143 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site