Avi Kivity wrote: > Dong, Eddie wrote: > > First, I doubt that memory slot count will really affect performance. > The memory slot structure is small and it is likely that all slots > will be kept in cache at all times. Walking all slots should take > a lot less > time than a vmexit, even if there are 16 slots. Placing the most > heavily used slots first reduces that time further.
Defintely it is small compare with vm exit. We will try to measure. > > But to the bigger picture. We're quite close to using user-allocated > memory for the guest, instead of kernel allocated memory. This means > that userspace will allocate a memory region and assign it to kvm as a > memory slot. On x86-64, where we have a large address space, > this means > that all of memory can be in just one slot (well, slots also > allow us to > do tracking of dirty pages on a subset of memory, so maybe three slots > are needed). In effect, the Linux process page tables become the g2h > (or p2m) tables, and access to guest memory is a simple > copy_to_user()/copy_from_user(). There are couple reasons that g2h can't server this. A VT-d device or EPT/NPT table need to translate from guest physical to machine physical address, while g2h uses host mode va as index. Other reason is that g2h also include host user space memory & kernel memory which guest should never touch. (A bad programmed VT-d device may modify the memory listed by VT-d table). Dirty tracking can certainly be serviced even using p2m solely. > > User-allocated memory will enable the following features: > - s390 support > - guest swapping > - page migration (where a guest is migrated from one NUMA node > to another) > - in conjunction with a de-duplicating file system, page sharing > among guests > - inter-guest shared memory (mmap() one file in two or more guests) > - easier use of huge pages > - more? > This doesn't conflict with my suggestion though the p2m table then need to be dynamically modifed in case swapping happens. thx,eddie ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
