On 18.07.2011, at 20:45, Scott Wood wrote:

> On Mon, 18 Jul 2011 11:49:10 +0200
> Alexander Graf <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to