search for: get_from_free_page_list

...it should be easier to succeed in allocation of large buffer. If that allocation fails, that implies that nothing would be got from the 4MB free page list. > > I think the proportional allocation is simpler compared to other approaches like > - scattered buffer, which will complicate the get_from_free_page_list implementation; > - one buffer to call get_from_free_page_list multiple times, which needs get_from_free_page_list to maintain states.. also too complicated. > > Best, > Wei > That's more reasonable, but question remains what to do if that value exceeds MAX_ORDER. I'd say...

...it should be easier to succeed in allocation of large buffer. If that allocation fails, that implies that nothing would be got from the 4MB free page list. > > I think the proportional allocation is simpler compared to other approaches like > - scattered buffer, which will complicate the get_from_free_page_list implementation; > - one buffer to call get_from_free_page_list multiple times, which needs get_from_free_page_list to maintain states.. also too complicated. > > Best, > Wei > That's more reasonable, but question remains what to do if that value exceeds MAX_ORDER. I'd say...

...; > > > > + 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 free list for us? > > > > > > We could also avoid the 1st allocation then - just build a list > > > > > > of these. > > > > > That wouldn't be a good choice for us. If we check how the regular > > > > > allocat...

...; > > > > + 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 free list for us? > > > > > > We could also avoid the 1st allocation then - just build a list > > > > > > of these. > > > > > That wouldn't be a good choice for us. If we check how the regular > > > > > allocat...

...; > > > > + 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 free list for us? > > > > We could also avoid the 1st allocation then - just build a list > > > > of these. > > > That wouldn't be a good choice for us. If we check how the regular > > > allocation works, there are many many things we...

...; > > > > + 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 free list for us? > > > > We could also avoid the 1st allocation then - just build a list > > > > of these. > > > That wouldn't be a good choice for us. If we check how the regular > > > allocation works, there are many many things we...

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

...a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2002,6 +2002,7 @@ extern void free_area_init(unsigned long * zones_size); extern void free_area_init_node(int nid, unsigned long * zones_size, unsigned long zone_start_pfn, unsigned long *zholes_size); extern void free_initmem(void); +uint32_t get_from_free_page_list(int order, __le64 buf[], uint32_t size); /* * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 07b3c23..7c816d9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5043,6 +5043,58 @@ void show_free_areas(unsigned...

...t; > > > > > > > > + > > > > > > > > > + 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 free list for us? > > > > > > > > We could also avoid the 1st allocation then - just build a list > > > > > > > > of these. > > > > > > > That wouldn't be a good choice for us. If we check how the regular &g...

...t; > > > > > > > > + > > > > > > > > > + 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 free list for us? > > > > > > > > We could also avoid the 1st allocation then - just build a list > > > > > > > > of these. > > > > > > > That wouldn't be a good choice for us. If we check how the regular &g...

...m.h @@ -2007,6 +2007,9 @@ extern void free_area_init(unsigned long * zones_size); extern void free_area_init_node(int nid, unsigned long * zones_size, unsigned long zone_start_pfn, unsigned long *zholes_size); extern void free_initmem(void); +unsigned long max_free_page_blocks(int order); +int get_from_free_page_list(int order, struct list_head *pages, + unsigned int size, unsigned long *loaded_num); /* * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1521100..b67839b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@...

...large memory, it should be easier to succeed in allocation of large buffer. If that allocation fails, that implies that nothing would be got from the 4MB free page list. I think the proportional allocation is simpler compared to other approaches like - scattered buffer, which will complicate the get_from_free_page_list implementation; - one buffer to call get_from_free_page_list multiple times, which needs get_from_free_page_list to maintain states.. also too complicated. Best, Wei

...> allocation of large buffer. If that allocation fails, that implies that nothing > would be got from the 4MB free page list. > > > > I think the proportional allocation is simpler compared to other > > approaches like > > - scattered buffer, which will complicate the get_from_free_page_list > > implementation; > > - one buffer to call get_from_free_page_list multiple times, which needs > get_from_free_page_list to maintain states.. also too complicated. > > > > Best, > > Wei > > > > That's more reasonable, but question remains what to...

On Fri, Jun 15, 2018 at 2:08 PM Wei Wang <wei.w.wang at intel.com> wrote: > > This patch adds a function to get free pages blocks from a free page > list. The obtained free page blocks are hints about free pages, because > there is no guarantee that they are still on the free page list after > the function returns. Ack. This is the kind of simple interface where I don't

On Fri, Jun 15, 2018 at 2:08 PM Wei Wang <wei.w.wang at intel.com> wrote: > > This patch adds a function to get free pages blocks from a free page > list. The obtained free page blocks are hints about free pages, because > there is no guarantee that they are still on the free page list after > the function returns. Ack. This is the kind of simple interface where I don't

On Fri, Jun 15, 2018 at 12:43:10PM +0800, Wei Wang wrote: > +/** > + * get_from_free_page_list - get free page blocks from a free page list > + * @order: the order of the free page list to check > + * @buf: the array to store the physical addresses of the free page blocks > + * @size: the array size > + * > + * This function offers hints about free pages. There is no guarantee...

...ge -j4): - Live Migration Time (average) Optimization v.s. Legacy = 1420ms v.s. 2528ms --> ~44% reduction - Linux Compilation Time Optimization v.s. Legacy = 5min8s v.s. 5min12s --> no obvious difference ChangeLog: v34->v35: - mm: - get_from_free_page_list: use a list of page blocks as buffers to store addresses, instead of an array of buffers. - virtio-balloon: - Allocate a list of buffers, instead of an array of buffers. - Used buffers are freed after host puts the buffer to the used ring; unused buffers are fr...

[ Sorry for slow reply, my travels have made a mess of my inbox ] On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > Linus, do you think it would be ok to have get_from_free_page_list > actually pop entries from the free list and use them as the buffer > to store PAs? Honestly, what I think the best option would be is to get rid of this interface *entirely*, and just have the balloon code do #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN | __GFP_THISNODE | __GFP_...

[ Sorry for slow reply, my travels have made a mess of my inbox ] On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > Linus, do you think it would be ok to have get_from_free_page_list > actually pop entries from the free list and use them as the buffer > to store PAs? Honestly, what I think the best option would be is to get rid of this interface *entirely*, and just have the balloon code do #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN | __GFP_THISNODE | __GFP_...