On 14.02.19 10:08, Wang, Wei W wrote: > On Wednesday, February 13, 2019 5:19 PM, David Hildenbrand wrote: >> If you have to resize/alloc/coordinate who will report, you will need >> locking. >> Especially, I doubt that there is an atomic xbitmap (prove me wrong :) ). > > Yes, we need change xbitmap to support it. > > Just thought of another option, which would be better: > - xb_preload in prepare_alloc_pages to pre-allocate the bitmap memory; > - xb_set/clear the bit under the zone->lock, i.e. in rmqueue and free_one_page
And how to preload without locking? > > will not be concurrently called to race on the same bitmap. > And we don't add any new locks to generate new doubts. > Also, we can probably remove the arch_alloc/free_page part. > > For the first step, we could optimize VIRTIO_BALLOON_F_FREE_PAGE_HINT for the > live migration optimization: > - just replace alloc_pages(VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG, > VIRTIO_BALLOON_FREE_PAGE_ORDER) > with get_free_page_hints() > > get_free_page_hints() was designed to clear the bit, and need > put_free_page_hints() to set it later after host finishes madvise. For the > live migration usage, as host doesn't free the backing host pages, so we can > give get_free_page_hints a parameter option to not clear the bit for this > usage. It will be simpler and faster. > > I think get_free_page_hints() to read hints via bitmaps should be much faster > than that allocation function, which takes around 15us to get a 4MB block. > Another big bonus is that we don't need free_pages() to return all the pages > back to buddy (it's a quite expensive operation too) when migration is done. > > For the second step, we can improve ballooning, e.g. a new feature > VIRTIO_BALLOON_F_ADVANCED_BALLOON to use the same get_free_page_hints() and > another put_free_page_hints(), along with the virtio-balloon's report_vq and > ack_vq to wait for the host's ack before making the free page ready. > (I think waiting for the host ack is the overhead that the guest has to > suffer for enabling memory overcommitment, and even with this v8 patch series > it also needs to do that. The optimization method was described yesterday) > As I already said, I don't like that approach, because it has the fundamental issue of page allocs getting blocked. That does not mean that it is bad, but that I think what Nitesh has is superior in that sense. Of course, things like "how to enable/disable", and much more needs to be clarified. If you believe in your approach, feel free to come up with a prototype. Especially the "no global locking" could be tricky in my opinion :) >> Yes, but as I mentioned this has other drawbacks. Relying on a a guest to >> free >> up memory when you really need it is not going to work. > > why not working? Host can ask at any time (including when not urgently need > it) depending on the admin's configuration. Because any heuristic like "I am running out of memory, quickly ask someone who will need time to respond" is prone to fail in some scenarios. It might work for many, but it is not a "I am running out of memory, oh look, this page has been flagged via madv(FREE), let's just take that." > >> It might work for >> some scenarios but should not dictate the design. It is a good start though >> if >> it makes things easier. > > Enabling/disabling free page hintning by the hypervisor via some >> mechanism is on the other hand a good idea. "I have plenty of free space, >> don't worry". > > Also guests are not treated identically, host can decide whom to offer the > free pages first (offering free pages will cause the guest some performance > drop). Yes, it should definetly be configurable somehow. You don't want free page hinting always and in any setup. -- Thanks, David / dhildenb
