[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120628124546.83a829f3.yoshikawa.takuya@oss.ntt.co.jp>
Date: Thu, 28 Jun 2012 12:45:46 +0900
From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>
To: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
Cc: avi@...hat.com, mtosatti@...hat.com, agraf@...e.de,
paulus@...ba.org, aarcange@...hat.com, kvm@...r.kernel.org,
kvm-ppc@...r.kernel.org, linux-kernel@...r.kernel.org,
takuya.yoshikawa@...il.com
Subject: Re: [PATCH 5/6] KVM: Separate rmap_pde from
kvm_lpage_info->write_count
On Thu, 28 Jun 2012 11:12:51 +0800
Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists