Messages in this thread | | | Date | Thu, 26 May 2011 21:20:38 +0300 | From | Avi Kivity <> | Subject | Re: [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.
| |