[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] [PATCH][RFC]discontig memory support
>From: Kouya SHIMURA [mailto:kouya@xxxxxxxxxxxxxx] >Sent: 2006年4月4日 10:18 >Tian, Kevin writes: > > If you can measure the TLB miss ratio of accessing vmemmap, that >could > > help a lot to make right choice. > >My guess is that the TLB miss ratio is quite worse because >vmemmap(frame_table) is usually accessed only by grant table >operation >and the locality seems to be less. > >I think if the overhead of TLB miss would be enough light, the >performance of VIRTUAL_MEM_MAP is better than SPARCEMEM. But >SPARCMEM >is more extensible to implement other functions. One is grant table operation, another is the memory interface used by balloon driver, DMA, etc where such relationship will be queried. I'm not sure about frequency of grant table operations, but virtual drivers depend on that interface heavily, especially for vnif. When later those stuffs are ready to test, then you may measure whether the access to vmemmap is efficient. A rough thought is, if most access to vmemmap results a TLB miss, and then go to physical mode, walk the tree page table with TLB insertion, back to virtual mode, it will become more efficient to walk the page table directly which would then look like SPARSEMEM. Or else vmemmap is the one as you said if overhead of TLB miss doesn't matter in the whole path. All depends on data. :-) > > >[TODO] > > > * cleanup #ifdefs of CONFIG_VIRTUAL_MEM_MAP >It means that CONFIG_VIRTUAL_MEM_MAP originated in Linux are still >scattered in source code and I will do cleanup. Good, and sorry for my misunderstanding. Thanks, Kevin _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |