On Thu, 28 Jun 2012 11:12:51 +0800
Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> wrote:
> > struct kvm_arch_memory_slot {
> > + unsigned long *rmap_pde[KVM_NR_PAGE_SIZES - 1];
> > struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
> > };
> >
>
> It looks little complex than before - need manage more alloc-ed/freed buffers.
Actually I want to integrate rmap and rmap_pde in the future:
rmap[KVM_NR_PAGE_SIZES]
For this we need to modify some unrelated ppc code, so I just
avoided the integration in this series.
Note: write_count: 4 bytes, rmap_pde: 8 bytes. So we are wasting
extra paddings by packing them into lpage_info.
> Why not just introduce a function to get the next rmap? Something like this:
I want to eliminate this kind of overheads.
Thanks,
Takuya
> static unsigned long *get_next_rmap(unsigned long *rmap, int level)
> {
> struct kvm_lpage_info *linfo
>
> if (level == 1)
> return rmap++
>
> linfo = container_of(rmap, struct kvm_lpage_info, rmap_pde);
>
> return &(++linfo)->rmap_pde
> }
>
> [ Completely untested ]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
