search for: __gfp_atomic

...*), GFP_KERNEL); > Instead of all this mess, how about get_free_pages here as well? Sounds good, will replace kmalloc_array with __get_free_pages(), but still need the above calculation to get max_array_num. > > Also why do we need GFP_KERNEL for this? I guess it is better to use "__GFP_ATOMIC | __GFP_NOMEMALLOC", thanks. > > >> + if (!arrays) >> + return NULL; >> + >> + for (i = 0; i < max_array_num; i++) { > So we are getting a ton of memory here just to free it up a bit later. > Why doesn't get_from_free_page_list get the pages from fr...

...x_array_num; i++) { So we are getting a ton of memory here just to free it up a bit later. Why doesn't get_from_free_page_list get the pages from free list for us? We could also avoid the 1st allocation then - just build a list of these. > + arrays[i] = > + (__le64 *)__get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, > + ARRAY_ALLOC_ORDER); Coding style says: Descendants are always substantially shorter than the parent and are placed substantially to the right. > + if (!arrays[i]) { Also if it does fail (small guest), shall we try with less arrays? > + /* > + * I...

...x_array_num; i++) { So we are getting a ton of memory here just to free it up a bit later. Why doesn't get_from_free_page_list get the pages from free list for us? We could also avoid the 1st allocation then - just build a list of these. > + arrays[i] = > + (__le64 *)__get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, > + ARRAY_ALLOC_ORDER); Coding style says: Descendants are always substantially shorter than the parent and are placed substantially to the right. > + if (!arrays[i]) { Also if it does fail (small guest), shall we try with less arrays? > + /* > + * I...

...place kmalloc_array with __get_free_pages(), Or alloc_pages, __ APIs are better avoided if possible. > but still > need the above calculation to get max_array_num. Maybe alloc_pages? > > > > Also why do we need GFP_KERNEL for this? > > I guess it is better to use "__GFP_ATOMIC | __GFP_NOMEMALLOC", thanks. > > > > > > > > + if (!arrays) > > > + return NULL; > > > + > > > + for (i = 0; i < max_array_num; i++) { > > So we are getting a ton of memory here just to free it up a bit later. > > Why doesn&...

...place kmalloc_array with __get_free_pages(), Or alloc_pages, __ APIs are better avoided if possible. > but still > need the above calculation to get max_array_num. Maybe alloc_pages? > > > > Also why do we need GFP_KERNEL for this? > > I guess it is better to use "__GFP_ATOMIC | __GFP_NOMEMALLOC", thanks. > > > > > > > > + if (!arrays) > > > + return NULL; > > > + > > > + for (i = 0; i < max_array_num; i++) { > > So we are getting a ton of memory here just to free it up a bit later. > > Why doesn&...

.... > > Best, > Wei > That's more reasonable, but question remains what to do if that value exceeds MAX_ORDER. I'd say maybe tell host we can't report it. Also allocating it with GFP_KERNEL is out. You only want to take it off the free list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. Also you can't allocate this on device start. First totalram_pages can change. Second that's too much memory to tie up forever. -- MST

.... > > Best, > Wei > That's more reasonable, but question remains what to do if that value exceeds MAX_ORDER. I'd say maybe tell host we can't report it. Also allocating it with GFP_KERNEL is out. You only want to take it off the free list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. Also you can't allocate this on device start. First totalram_pages can change. Second that's too much memory to tie up forever. -- MST

On Tue, Jun 19, 2018 at 08:13:37PM +0800, Wei Wang wrote: > On 06/19/2018 11:05 AM, Michael S. Tsirkin wrote: > > On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: > > > On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > > > > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > > > > Not necessarily, I think. We have

...MAX_ORDER_NR_PAGES; total_arrays = max_hints / hints_per_array + !!(max_hints % hints_per_array); arrays = kmalloc(total_arrays * sizeof(unsigned long), GFP_KERNEL); for (i = 0; i < total_arrays; i++) { arrays[i] = __get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, MAX_ORDER - 1); if (!arrays[i]) goto out; } - the mm API needs to be changed to support storing hints to multiple separated arrays offered by the caller. Best, Wei

...other hand, large guests being large mostly because the guests need to use large memory. In that case, they usually won't have that much free memory to report. > > Also allocating it with GFP_KERNEL is out. You only want to take it off the free > list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. Sounds good, thanks. > Also you can't allocate this on device start. First totalram_pages can change. > Second that's too much memory to tie up forever. Yes, makes sense. Best, Wei

On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates the > support of reporting hints of guest free pages to host via virtio-balloon. > > Host requests the guest to report free page hints by sending a command > to the guest via setting the VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT bit > of the host_cmd

On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates the > support of reporting hints of guest free pages to host via virtio-balloon. > > Host requests the guest to report free page hints by sending a command > to the guest via setting the VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT bit > of the host_cmd

...ollowing this logic small guests don't have a lot of memory to report at all. Could you remind me why are we considering this optimization then? > > > > Also allocating it with GFP_KERNEL is out. You only want to take it off the free > > list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. > > Sounds good, thanks. > > > Also you can't allocate this on device start. First totalram_pages can change. > > Second that's too much memory to tie up forever. > > Yes, makes sense. > > Best, > Wei

..._ALLOC_ORDER); + max_array_num = max_entries / entries_per_array + + !!(max_entries % entries_per_array); + arrays = kmalloc_array(max_array_num, sizeof(__le64 *), GFP_KERNEL); + if (!arrays) + return NULL; + + for (i = 0; i < max_array_num; i++) { + arrays[i] = + (__le64 *)__get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, + ARRAY_ALLOC_ORDER); + if (!arrays[i]) { + /* + * If any one of the arrays fails to be allocated, it + * implies that the free list that we are interested + * in is empty, and there is no need to continue the + * reporting. So just free what's allocate...

This patch series is separated from the previous "Virtio-balloon Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this series enables the virtio-balloon driver to report hints of guest free pages to the host. It can be used to accelerate live migration of VMs. Here is an introduction of this usage: Live migration needs to transfer the VM's

This patch series is separated from the previous "Virtio-balloon Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this series enables the virtio-balloon driver to report hints of guest free pages to the host. It can be used to accelerate live migration of VMs. Here is an introduction of this usage: Live migration needs to transfer the VM's

This patch series is separated from the previous "Virtio-balloon Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this series enables the virtio-balloon driver to report hints of guest free pages to the host. It can be used to accelerate live migration of VMs. Here is an introduction of this usage: Live migration needs to transfer the VM's