On Thu, 28 Jun 2012 20:39:55 +0300 Avi Kivity <avi@xxxxxxxxxx> wrote: > > Note: write_count: 4 bytes, rmap_pde: 8 bytes. So we are wasting > > extra paddings by packing them into lpage_info. > > The wastage is quite low since it's just 4 bytes per 2MB. Yes. > >> Why not just introduce a function to get the next rmap? Something like this: > > > > I want to eliminate this kind of overheads. > > I don't think the overhead is significant. rmap walk speed is largely a > function of cache misses IMO, and we may even be adding cache misses by > splitting lpage_info. Maybe. But as far as I can see, write_count does not gain much from being close to rmap_pde. > But I still think it's the right thing since it simplifies the code. After the rmap integration, we can remove if (likely(level == PT_PAGE_TABLE_LEVEL)) heuristics from __gfn_to_rmap(). As a bonus, the helper will become enough simple to be always inlined which reduces some function calls. > Maybe we should add a prefetch() on write_count do mitigate the > overhead, if it starts showing up in profiles. OK, I will post rmap integration work as soon as possible, but it still needs to be synced with unrelated ppc works at some point in the future: so please take that separately from this series. Thanks, Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
