[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
On Thu, Jan 05, hongkaixing@xxxxxxxxxx wrote: > # HG changeset patch > # User hongkaixing<hongkaixing@xxxxxxxxxx> > # Date 1325149704 -28800 > # Node ID 052727b8165ce6e05002184ae894096214c8b537 > # Parent 54a5e994a241a506900ee0e197bb42e5f1d8e759 > xenpaging:add a new array to speed up page-in in xenpaging > > This patch adds a new array named page_out_index to reserve the victim's > index. > When page in a page,it has to go through a for loop from 0 to num_pages to > find > the right page to read,and it costs much time in this loop.After adding the > page_out_index array,it just reads the arrry to get the right page,and saves > much time. > > The following is a xenpaging test on suse11-64 with 4G memories. > > Nums of page_out pages Page out time Page in time(in unstable code) > Page in time(apply this patch) > 512M(131072) 2.6s 540s > 530s > 2G(524288) 15.5s 2088s > 2055s Thanks for your work on this. Is the page-out time for 512M really that fast? For me page-out is still really slow even when the pagefile is in tmpfs. It takes several minutes, I get around 4MB/s. page-in is around 20MB/s. Wether an extra array is needed, we have to decide as it costs some runtime memory. I was thinking already about better bitop functions, like xc_find_next_bit_set and similar, just what xenpaging needs, to remove the test bits one-by-one. As for the new page-in op, there was some offline discussion about doing page-in/page-out differently. If these ideas make into xen-unstable most of domctls will disappear, and also the mmap to trigger page-in is not needed anymore. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |