search for: page_info_item

...esp_buf_size, > + GFP_KERNEL); > + if (new_resp_data) { > + kfree(vb->resp_data); > + vb->resp_data = new_resp_data; > + vb->resp_buf_size *= 2; What happens to the data in ->resp_data at this point? Doesn't this just throw it away? ... > +struct page_info_item { > + __le64 start_pfn : 52; /* start pfn for the bitmap */ > + __le64 page_shift : 6; /* page shift width, in bytes */ > + __le64 bmap_len : 6; /* bitmap length, in bytes */ > +}; Is 'bmap_len' too short? a 64-byte buffer is a bit tiny. Right? > +static int mark_unused...

...esp_buf_size, > + GFP_KERNEL); > + if (new_resp_data) { > + kfree(vb->resp_data); > + vb->resp_data = new_resp_data; > + vb->resp_buf_size *= 2; What happens to the data in ->resp_data at this point? Doesn't this just throw it away? ... > +struct page_info_item { > + __le64 start_pfn : 52; /* start pfn for the bitmap */ > + __le64 page_shift : 6; /* page shift width, in bytes */ > + __le64 bmap_len : 6; /* bitmap length, in bytes */ > +}; Is 'bmap_len' too short? a 64-byte buffer is a bit tiny. Right? > +static int mark_unused...

...t; > + vb->resp_data = new_resp_data; > > + vb->resp_buf_size *= 2; > > What happens to the data in ->resp_data at this point? Doesn't this just > throw it away? > Yes, so we should make sure the data in resp_data is not inuse. > ... > > +struct page_info_item { > > + __le64 start_pfn : 52; /* start pfn for the bitmap */ > > + __le64 page_shift : 6; /* page shift width, in bytes */ > > + __le64 bmap_len : 6; /* bitmap length, in bytes */ }; > > Is 'bmap_len' too short? a 64-byte buffer is a bit tiny. Right? > Curr...

...it away? > > Yes, so we should make sure the data in resp_data is not inuse. But doesn't it have valid data that we just collected and haven't told the hypervisor about yet? Aren't we throwing away good data that cost us something to collect? >> ... >>> +struct page_info_item { >>> + __le64 start_pfn : 52; /* start pfn for the bitmap */ >>> + __le64 page_shift : 6; /* page shift width, in bytes */ What does a page_shift "in bytes" mean? :) >>> + __le64 bmap_len : 6; /* bitmap length, in bytes */ }; >> >> Is 'bmap_l...

...it away? > > Yes, so we should make sure the data in resp_data is not inuse. But doesn't it have valid data that we just collected and haven't told the hypervisor about yet? Aren't we throwing away good data that cost us something to collect? >> ... >>> +struct page_info_item { >>> + __le64 start_pfn : 52; /* start pfn for the bitmap */ >>> + __le64 page_shift : 6; /* page shift width, in bytes */ What does a page_shift "in bytes" mean? :) >>> + __le64 bmap_len : 6; /* bitmap length, in bytes */ }; >> >> Is 'bmap_l...

...) * into the buddy system. The freed pages will be poisoned with pattern diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6de9440..d5a5952 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4428,6 +4428,78 @@ void show_free_areas(unsigned int filter) show_swap_cache_info(); } +struct page_info_item { + __le64 start_pfn : 52; /* start pfn for the bitmap */ + __le64 page_shift : 6; /* page shift width, in bytes */ + __le64 bmap_len : 6; /* bitmap length, in bytes */ +}; + +static int mark_unused_pages(struct zone *zone, + unsigned long *unused_pages, unsigned long size, + int order, unsigne...

This patch set contains two parts of changes to the virtio-balloon. One is the change for speeding up the inflating & deflating process, the main idea of this optimization is to use bitmap to send the page information to host instead of the PFNs, to reduce the overhead of virtio data transmission, address translation and madvise(). This can help to improve the performance by about 85%.

This patch set contains two parts of changes to the virtio-balloon. One is the change for speeding up the inflating & deflating process, the main idea of this optimization is to use bitmap to send the page information to host instead of the PFNs, to reduce the overhead of virtio data transmission, address translation and madvise(). This can help to improve the performance by about 85%.