On 07/11/2012 02:03 AM, Minchan Kim wrote: > On 07/03/2012 06:15 AM, Seth Jennings wrote: >> zsmapbench measures the copy-based mapping at ~560 cycles for a >> map/unmap operation on spanned object for both KVM guest and bare-metal, >> while the page table mapping was ~1500 cycles on a VM and ~760 cycles >> bare-metal. The cycles for the copy method will vary with >> allocation size, however, it is still faster even for the largest >> allocation that zsmalloc supports. >> >> The result is convenient though, as mempcy is very portable :) > > Today, I tested zsmapbench in my embedded board(ARM). > tlb-flush is 30% faster than copy-based so it's always not win. > I think it depends on CPU speed/cache size. > > zram is already very popular on embedded systems so I want to use > it continuously without 30% big demage so I want to keep our old approach > which supporting local tlb flush. > > Of course, in case of KVM guest, copy-based would be always bin win. > So shouldn't we support both approach? It could make code very ugly > but I think it has enough value. > > Any thought? Thanks for testing on ARM. I can add the pgtable assisted method back in, no problem. The question is by which criteria are we going to choose which method to use? By arch (i.e. ARM -> pgtable assist, x86 -> copy, other archs -> ?)? Also, what changes did you make to zsmapbench to measure elapsed time/cycles on ARM? Afaik, rdtscll() is not supported on ARM. Thanks, Seth _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
