On Mon, 18 Jul 2011 11:49:10 +0200 Alexander Graf <agraf@xxxxxxx> wrote: > On 08.07.2011, at 01:41, Scott Wood wrote: > > > @@ -63,7 +64,9 @@ static DEFINE_PER_CPU(struct pcpu_id_table, pcpu_sids); > > * The valid range of shadow ID is [1..255] */ > > static DEFINE_PER_CPU(unsigned long, pcpu_last_used_sid); > > > > -static unsigned int tlb1_entry_num; > > +static unsigned int tlb_host_entries[2]; > > +static unsigned int tlb_host_ways[2]; > > +static unsigned int tlb_host_sets[2]; > > The 2 probably means "number of host TLBs", right? Isn't there a #define for this? Looks like there is. > In fact, it might be even more readable if we just shoved those into a > struct: > tlb_host_entries[1] would then become host_tlb[1].entries for example :). OK. > Also, since you're putting knowledge about the target MMU into this anyways (2 TLBs), This is the host MMU, not target. > can we prepopulate the contents of these and declare them const? The > compiler should then be able to optimize the code a bit more. We populate these at runtime. TLB0 ways/entries is different on e500v1 versus e500v2. TLB1 entries is different on e500mc, though we don't support a single kernel image with e500v2 and e500mc. And who knows what might happen in the future. As far as optimization goes, we should see what the bottlenecks are first. > In fact, reading the code a bit more, we could use the same information for the guest side, no? So we could have a host_tlb and a guest_tlb info struct and fold some of your helper > functions below to merely accessing one of the two globals. guest tlb is not a global. We can have multiple vcpus, and their tlbs are not necessarily configured the same. -Scott -- 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
