On 18.07.2011, at 20:45, Scott Wood wrote: > 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. Yes, that was my point. We're compiling the kernel for a specific CPU anyways, so it might make sense to just base on that knowledge. > >> 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. I agree - just fantasizing here. > >> 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. Yes, sorry for being so fuzzy in terminology here. You know what I meant :). Host info global, vcpu info local of course. Alex -- 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
