On 8/12/19 4:04 PM, Nitesh Narayan Lal wrote: > On 8/12/19 2:47 PM, Alexander Duyck wrote: >> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal <nitesh@xxxxxxxxxx> wrote: >>> This patch introduces the core infrastructure for free page reporting in >>> virtual environments. It enables the kernel to track the free pages which >>> can be reported to its hypervisor so that the hypervisor could >>> free and reuse that memory as per its requirement. >>> >>> While the pages are getting processed in the hypervisor (e.g., >>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss >>> would be possible. To avoid such a situation, these pages are >>> temporarily removed from the buddy. The amount of pages removed >>> temporarily from the buddy is governed by the backend(virtio-balloon >>> in our case). >>> >>> To efficiently identify free pages that can to be reported to the >>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big >>> chunks are reported to the hypervisor - especially, to not break up THP >>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits >>> in the bitmap are an indication whether a page *might* be free, not a >>> guarantee. A new hook after buddy merging sets the bits. >>> >>> Bitmaps are stored per zone, protected by the zone lock. A workqueue >>> asynchronously processes the bitmaps, trying to isolate and report pages >>> that are still free. The backend (virtio-balloon) is responsible for >>> reporting these batched pages to the host synchronously. Once reporting/ >>> freeing is complete, isolated pages are returned back to the buddy. >>> >>> Signed-off-by: Nitesh Narayan Lal <nitesh@xxxxxxxxxx> >> So if I understand correctly the hotplug support for this is still not >> included correct? > > That is correct, I have it as an ongoing-item in my cover-email. > In case, we decide to go with this approach do you think it is a blocker? I am planning to defer memory hotplug/hotremove support for the future. Due to following reasons: * I would like to first get a basic framework ready and merged (in case we decide to go ahead with this approach) and then build on top of it. * Memory hotplug/hotremove is not a primary use case in our mind right now and hence I am not considering this as a blocker for the first step. Following are the items which I intend to address before my next submission: * Use zone flag and reference counter to track the number of zones requesting page reporting. * Move the bitmap and its respective fields into a structure whose rcu-protected pointer object is maintained on a per-zone basis. * Pick Alexander's patch for page poisoning support and test them with my patch set. (@Alexander: I will keep your signed-off for these patches to indicate you are the original author, please do let me know there is a better way to give credit). * Address other suggestions/comments received on v12. Looking forward to any suggestions/comments. [...] > + > + /* assign the configuration object provided by the backend */ > + rcu_assign_pointer(page_reporting_conf, phconf); > + > +out: > + mutex_unlock(&page_reporting_mutex); > + return ret; > +} > +EXPORT_SYMBOL_GPL(page_reporting_enable); > -- > 2.21.0 > -- Thanks Nitesh
