search for: madv_free

...ge in the VM, which are called when > pages are freed, and allocated, respectively. > > Nitesh Lal (on the CC list) is working on a way > to efficiently batch recently freed pages for > free page hinting to the hypervisor. > > If that is done efficiently enough (eg. with > MADV_FREE on the hypervisor side for lazy freeing, > and lazy later re-use of the pages), do we still > need the harder to use batch interface from this > patch? > David's opinion incoming: No, I think proper free page hinting would be the optimum solution, if done right. This would avoid t...

...ge in the VM, which are called when > pages are freed, and allocated, respectively. > > Nitesh Lal (on the CC list) is working on a way > to efficiently batch recently freed pages for > free page hinting to the hypervisor. > > If that is done efficiently enough (eg. with > MADV_FREE on the hypervisor side for lazy freeing, > and lazy later re-use of the pages), do we still > need the harder to use batch interface from this > patch? > David's opinion incoming: No, I think proper free page hinting would be the optimum solution, if done right. This would avoid t...

...18:44, Rik van Riel wrote: > > > > Nitesh Lal (on the CC list) is working on a way > > > to efficiently batch recently freed pages for > > > free page hinting to the hypervisor. > > > > > > If that is done efficiently enough (eg. with > > > MADV_FREE on the hypervisor side for lazy freeing, > > > and lazy later re-use of the pages), do we still > > > need the harder to use batch interface from this > > > patch? > > > > > > > David's opinion incoming: > > > > No, I think proper f...

...18:44, Rik van Riel wrote: > > > > Nitesh Lal (on the CC list) is working on a way > > > to efficiently batch recently freed pages for > > > free page hinting to the hypervisor. > > > > > > If that is done efficiently enough (eg. with > > > MADV_FREE on the hypervisor side for lazy freeing, > > > and lazy later re-use of the pages), do we still > > > need the harder to use batch interface from this > > > patch? > > > > > > > David's opinion incoming: > > > > No, I think proper f...

...denbrand wrote: > On 20.06.2017 18:44, Rik van Riel wrote: > > Nitesh Lal (on the CC list) is working on a way > > to efficiently batch recently freed pages for > > free page hinting to the hypervisor. > > > > If that is done efficiently enough (eg. with > > MADV_FREE on the hypervisor side for lazy freeing, > > and lazy later re-use of the pages), do we still > > need the harder to use batch interface from this > > patch? > > > > David's opinion incoming: > > No, I think proper free page hinting would be the optimum so...

https://bugzilla.mindrot.org/show_bug.cgi?id=3537 Bug ID: 3537 Summary: OpenSSH build failed Product: Portable OpenSSH Version: -current Hardware: amd64 OS: Linux Status: NEW Severity: major Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org

...ed, and allocated, respectively. >>> >>> Nitesh Lal (on the CC list) is working on a way >>> to efficiently batch recently freed pages for >>> free page hinting to the hypervisor. >>> >>> If that is done efficiently enough (eg. with >>> MADV_FREE on the hypervisor side for lazy freeing, >>> and lazy later re-use of the pages), do we still >>> need the harder to use batch interface from this >>> patch? >>> >> David's opinion incoming: >> >> No, I think proper free page hinting would b...

...ed, and allocated, respectively. >>> >>> Nitesh Lal (on the CC list) is working on a way >>> to efficiently batch recently freed pages for >>> free page hinting to the hypervisor. >>> >>> If that is done efficiently enough (eg. with >>> MADV_FREE on the hypervisor side for lazy freeing, >>> and lazy later re-use of the pages), do we still >>> need the harder to use batch interface from this >>> patch? >>> >> David's opinion incoming: >> >> No, I think proper free page hinting would b...

...0888.497355000, size=133, blksize=4096, blocks=8, flags=0x800 } 67611 blazer_usb RET stat 0 67611 blazer_usb CALL close(0x4) 67611 blazer_usb RET close 0 67611 blazer_usb CALL setgroups(0x2,0x80149c000) 67611 blazer_usb RET setgroups 0 67611 blazer_usb CALL madvise(0x80149b000,0x3000,MADV_FREE) 67611 blazer_usb RET madvise 0 67611 blazer_usb CALL setgid(0x42) 67611 blazer_usb RET setgid 0 67611 blazer_usb CALL setuid(0x42) 67611 blazer_usb RET setuid 0 67611 blazer_usb CALL chdir(0x40e1bc) 67611 blazer_usb NAMI "/var/db/nut" 67611 blazer_usb RET chdir 0 676...

Please stop cc'ing me on things also sent to closed mailing lists (virtio-dev at lists.oasis-open.org). I'm happy to review things on open lists, but I'm not fond of the closed lists bouncing things at me. On 06/09/2017 03:41 AM, Wei Wang wrote: > Add a function to find a page block on the free list specified by the > caller. Pages from the page block may be used immediately

Please stop cc'ing me on things also sent to closed mailing lists (virtio-dev at lists.oasis-open.org). I'm happy to review things on open lists, but I'm not fond of the closed lists bouncing things at me. On 06/09/2017 03:41 AM, Wei Wang wrote: > Add a function to find a page block on the free list specified by the > caller. Pages from the page block may be used immediately

...'m kind of trying to bridge this a bit - I would like the interfaces that we build to at least superficially look like they might be reusable for other uses of hinting. Imagine that you don't have dirty tracking on the host. What would it take to still use hinting information, e.g. to call MADV_FREE on the pages guest gives us? I think you need to kick and you need to wait for host to consume the hint before page is reused. And we know madvise takes a lot of time sometimes, so locking out the free list does not sound like a good idea. That's why I was talking about kick out of lock, so t...

...called arch_free_page and arch_alloc_page in the VM, which are called when pages are freed, and allocated, respectively. Nitesh Lal (on the CC list) is working on a way to efficiently batch recently freed pages for free page hinting to the hypervisor. If that is done efficiently enough (eg. with MADV_FREE on the hypervisor side for lazy freeing, and lazy later re-use of the pages), do we still need the harder to use batch interface from this patch? -- All rights reversed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signatur...

...> pages are freed, and allocated, respectively. > > > > Nitesh Lal (on the CC list) is working on a way > > to efficiently batch recently freed pages for > > free page hinting to the hypervisor. > > > > If that is done efficiently enough (eg. with > > MADV_FREE on the hypervisor side for lazy freeing, > > and lazy later re-use of the pages), do we still > > need the harder to use batch interface from this > > patch? > > > David's opinion incoming: > > No, I think proper free page hinting would be the optimum solution...

...t; >>> > >>> Nitesh Lal (on the CC list) is working on a way > >>> to efficiently batch recently freed pages for > >>> free page hinting to the hypervisor. > >>> > >>> If that is done efficiently enough (eg. with > >>> MADV_FREE on the hypervisor side for lazy freeing, > >>> and lazy later re-use of the pages), do we still > >>> need the harder to use batch interface from this > >>> patch? > >>> > >> David's opinion incoming: > >> > >> No, I thi...

...emory bandwidth (there are some guys complaining abut this on the QEMU mailinglist) In the above results, the legacy part already has the zero page feature in use. > > b) we perform free page hinting using something that Nitesh proposed. We > get in QEMU blocks of free pages that we can MADV_FREE. In addition we > could e.g. clear the dirty bit of these pages in the dirty bitmap, to > hinder them from getting migrated. Right now the hinting mechanism is > synchronous (called from arch_free_page()) but we might be able to > convert it into something asynchronous. > > So we...

...emory bandwidth (there are some guys complaining abut this on the QEMU mailinglist) In the above results, the legacy part already has the zero page feature in use. > > b) we perform free page hinting using something that Nitesh proposed. We > get in QEMU blocks of free pages that we can MADV_FREE. In addition we > could e.g. clear the dirty bit of these pages in the dirty bitmap, to > hinder them from getting migrated. Right now the hinting mechanism is > synchronous (called from arch_free_page()) but we might be able to > convert it into something asynchronous. > > So we...

...ge this a bit - I would > like the interfaces that we build to at least superficially > look like they might be reusable for other uses of hinting. > > Imagine that you don't have dirty tracking on the host. > What would it take to still use hinting information, > e.g. to call MADV_FREE on the pages guest gives us? > > I think you need to kick and you need to wait for > host to consume the hint before page is reused. > And we know madvise takes a lot of time sometimes, > so locking out the free list does not sound like a > good idea. > > That's why I wa...

...don't consider this attempt not very practical in general, especially as it would rely on KSM right now, which is frowned upon by many people. > >> >> b) we perform free page hinting using something that Nitesh proposed. We >> get in QEMU blocks of free pages that we can MADV_FREE. In addition we >> could e.g. clear the dirty bit of these pages in the dirty bitmap, to >> hinder them from getting migrated. Right now the hinting mechanism is >> synchronous (called from arch_free_page()) but we might be able to >> convert it into something asynchronous....

On Fri, Jan 26, 2018 at 09:40:44AM +0800, Wei Wang wrote: > On 01/25/2018 09:49 PM, Michael S. Tsirkin wrote: > > On Thu, Jan 25, 2018 at 05:14:06PM +0800, Wei Wang wrote: > > > + > > > +static void report_free_page_func(struct work_struct *work) > > > +{ > > > + struct virtio_balloon *vb; > > > + int ret; > > > + > > > + vb =