Alexander Graf <ag...@suse.de> wrote: > On 19.06.2012, at 22:30, Benjamin Herrenschmidt wrote: > >> On Tue, 2012-06-19 at 16:59 +0200, Juan Quintela wrote: >>>>> - The hash table (mentioned above). This is just a big chunk of >>> memory >>>>> (it will routinely be 16M), so I really don't want to start >>> iterating >>>>> all elements, just a bulk load will do, and the size might actually >>> be >>>>> variable. >>> >>> This is going to kill migration download time. With current setup, we >>> just sent something like 1-2MB in stage 3 (i.e. after the machine is >>> down). Default downtime is 30ms, And 16MB is going to take around 1s >>> on gigabit ethenet. >>> >>> Once said that, if you told me the state that you want to sent, I can >>> take a look. >> >> Well, we don't have much of a choice unless we do something really fancy >> but that would be a second step... >> >> The MMU hash table on power is where all our translations go. What we >> could do is put in some knowledge about what translations are actually >> necessary for the guest and which ones can be rebuild (faulted in), >> essentially by adding knowledge to qemu/kvm about the "bolted" bit that >> the guests uses for translations that must not be evicted. >> >> However, that would require at least some interaction between the guest >> and qemu/kvm to enable the function since this bit is a guest SW >> construct (unless it got architected in recent PAPR, I need to dbl >> check). > > How is the problem different from RAM? It's a 16MB region that can be > accessed by the guest even during transfer time, so it can get dirty > during the migration. But we only need to really transfer the last > small delta at the end of the migration, right?
This was going to be my question. If we can do something like: send hash register, and get a bitmap of the ones that get changed, we should be good. Perhaps we need something "interesting" like removing old entries (no clue if they got just overwritten, or how they are replaced), and we should be good. Later, Juan.
