search for: for_each_zon

On Wed, Jul 12, 2017 at 08:40:20PM +0800, Wei Wang wrote: > This patch enables for_each_zone()/for_each_populated_zone() to be > invoked by a kernel module. ... for use by virtio balloon. > Signed-off-by: Wei Wang <wei.w.wang at intel.com> balloon seems to only use + for_each_populated_zone(zone) + for_each_migratetype_order(order, type) > --- >...

On Wed, Jul 12, 2017 at 08:40:20PM +0800, Wei Wang wrote: > This patch enables for_each_zone()/for_each_populated_zone() to be > invoked by a kernel module. ... for use by virtio balloon. > Signed-off-by: Wei Wang <wei.w.wang at intel.com> balloon seems to only use + for_each_populated_zone(zone) + for_each_migratetype_order(order, type) > --- >...

...sor to the guest in this case. How did you plan to use your original API which export struct page array then? > > This would address my main concern that the allocator internals would get > > outside of the allocator proper. > > What issue would it have to expose the internal, for_each_zone()? zone is a MM internal concept. No code outside of the MM proper should really care about zones. -- Michal Hocko SUSE Labs

...sor to the guest in this case. How did you plan to use your original API which export struct page array then? > > This would address my main concern that the allocator internals would get > > outside of the allocator proper. > > What issue would it have to expose the internal, for_each_zone()? zone is a MM internal concept. No code outside of the MM proper should really care about zones. -- Michal Hocko SUSE Labs

On Tue 25-07-17 19:56:24, Wei Wang wrote: > On 07/25/2017 07:25 PM, Michal Hocko wrote: > >On Tue 25-07-17 17:32:00, Wei Wang wrote: > >>On 07/24/2017 05:00 PM, Michal Hocko wrote: > >>>On Wed 19-07-17 20:01:18, Wei Wang wrote: > >>>>On 07/19/2017 04:13 PM, Michal Hocko wrote: > >>>[... > >>>>>All you should need is the

On Tue 25-07-17 19:56:24, Wei Wang wrote: > On 07/25/2017 07:25 PM, Michal Hocko wrote: > >On Tue 25-07-17 17:32:00, Wei Wang wrote: > >>On 07/24/2017 05:00 PM, Michal Hocko wrote: > >>>On Wed 19-07-17 20:01:18, Wei Wang wrote: > >>>>On 07/19/2017 04:13 PM, Michal Hocko wrote: > >>>[... > >>>>>All you should need is the

Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory statistics protocol, corresponding to 'Available' in /proc/meminfo. It indicates to the hypervisor how big the balloon can be inflated without pushing the guest system to swap. This metric would be very useful in VM orchestration software to improve memory management of different VMs under overcommit. Signed-off-by: Igor

Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory statistics protocol, corresponding to 'Available' in /proc/meminfo. It indicates to the hypervisor how big the balloon can be inflated without pushing the guest system to swap. This metric would be very useful in VM orchestration software to improve memory management of different VMs under overcommit. Signed-off-by: Igor

This patch enables for_each_zone()/for_each_populated_zone() to be invoked by a kernel module. Signed-off-by: Wei Wang <wei.w.wang at intel.com> --- mm/mmzone.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/mmzone.c b/mm/mmzone.c index a51c0a6..08a2a3a 100644 --- a/mm/mmzone.c +++ b/mm/mmzone.c @@ -13,6 +13,7 @...

...the guest. I think we also wouldn't be able to give a callback function from the hypervisor to the guest in this case. > > This would address my main concern that the allocator internals would get > outside of the allocator proper. What issue would it have to expose the internal, for_each_zone()? I think new code which would call it will also be strictly checked when they are pushed to upstream. Best, Wei

...ee page list, the info put on the ring is just (base address of the 2MB continuous memory, size=2M). > >>> This would address my main concern that the allocator internals would get >>> outside of the allocator proper. >> What issue would it have to expose the internal, for_each_zone()? > zone is a MM internal concept. No code outside of the MM proper should > really care about zones. I think this is also what Andrew suggested in the previous discussion: https://lkml.org/lkml/2017/3/16/951 Move the code to virtio-balloon and a little layering violation seems acceptabl...

...from using the above proposed callback mechanism and export what is needed to the hypervisor? > >>>This would address my main concern that the allocator internals would get > >>>outside of the allocator proper. > >>What issue would it have to expose the internal, for_each_zone()? > >zone is a MM internal concept. No code outside of the MM proper should > >really care about zones. > > I think this is also what Andrew suggested in the previous discussion: > https://lkml.org/lkml/2017/3/16/951 > > Move the code to virtio-balloon and a little la...

...from using the above proposed callback mechanism and export what is needed to the hypervisor? > >>>This would address my main concern that the allocator internals would get > >>>outside of the allocator proper. > >>What issue would it have to expose the internal, for_each_zone()? > >zone is a MM internal concept. No code outside of the MM proper should > >really care about zones. > > I think this is also what Andrew suggested in the previous discussion: > https://lkml.org/lkml/2017/3/16/951 > > Move the code to virtio-balloon and a little la...

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one by one; and 2) cmdq: a new virtqueue to send commands between the device and driver. Currently, it supports commands to report memory stats (replace the old statq mechanism) and report guest unused pages.

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one by one; and 2) cmdq: a new virtqueue to send commands between the device and driver. Currently, it supports commands to report memory stats (replace the old statq mechanism) and report guest unused pages.

This patch series implements two optimizations: 1) transfer pages in chuncks between the guest and host; 2) transfer the guest unused pages to the host so that they can be skipped to migrate in live migration. Changes: v8->v9: 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous implementation; 2) Simpler

This patch series implements two optimizations: 1) transfer pages in chuncks between the guest and host; 2) transfer the guest unused pages to the host so that they can be skipped to migrate in live migration. Changes: v8->v9: 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous implementation; 2) Simpler

This patch series implements the follow two things: 1) Optimization of balloon page transfer: instead of transferring balloon pages to host one by one, the new mechanism transfers them in chunks. 2) A mechanism to report info of guest unused pages: the pages have been unused at some time between when host sent command and when guest reported them. Host uses that by tracking memory changes and

This patch series implements the follow two things: 1) Optimization of balloon page transfer: instead of transferring balloon pages to host one by one, the new mechanism transfers them in chunks. 2) A mechanism to report info of guest unused pages: the pages have been unused at some time between when host sent command and when guest reported them. Host uses that by tracking memory changes and

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks, instead of one by one; and 2) cmdq: a new virtqueue to send commands between the device and driver. Currently, it supports commands to report memory stats (replace the old statq mechanism) and report guest unused pages. Liang Li