| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] unify vtlb and vhpt
tgingold@xxxxxxx wrote:
> Hi Kouya,
>
> to be honest I have mixed feelings about your patch. I like it but I
> don't really understand its purpose. See my comment.
>
> I still think it would be nice if the vTLB were TR-mapped.
This is same with sharing vTLB/VHPT memory. Single TR
or double TR (your case) can solve problem both.
>
>
> Quoting Kouya Shimura <kouya@xxxxxxxxxxxxxx>:
>
>> Dong, Eddie writes:
>>> This can be simply solved by increasing vTLB size, or
>>> use same memory with VHPT.
>>
>> The problem is, how much size is suitable?
>> There is a trade off. The larger size consumes a time for ptc.e
>> emulation and causes a serious slowdown for a Windows guest.
>
How frequently does Windows issue PTC.E? In current situation,
VHPT is 16MB, while vTLB is 32K, so I would think purging VHPT
is dominant.
> Ok.
>
>> Currently vTLB size is configurable but ordinary users
>> can't understand what vTLB is.
??? This is not true except the user(developer) doesn't
have virtualization concept. In my experience, I have trouble
to explain what is host VHPT in VMM for a guest, but pretty easy
to say the meaning of vTLB whose original meaning is guest
TLB. The issue in today's Xen/IA64 is
that so called vTLB is not equal to real guest TLB. (guest TLB
= vTR + vTLB + something in VHPT + something in machine TLB)
If you want to rename vTLB to something else, I will vote for Yes.
>> A purpose of this patch is to make users free from
>> setting vTLB size.
This is same with sharing memory between VTLB & VHPT.
>
> By merging vTLB and VHPT the user can't anymore set the size of the
> vTLB. This is obvious. But is your patch different from increasing
> vTLB size ? Did I miss a point ?
>
> I am not sure it is a good idea to remove vTLB size. On a real
> processor the TLB structure is fixed and defined.
Yes, but probably this is ok since vTLB isn't equal to guest TLB :(
Ideally guest TLB should have a fixed size.
Sharing memory makes concept clear for me. I.e. VHPT is VHPT,
while vTLB is those entries can't be put into VHPT.
With this patch, if a VTLB entry in collision chain has to become
head of VHPT table, it is really dilemma to put this to head or not.
GP fault for reserved bit could be used here with performance
penalty but it is really not good and it could happen again as if the
VHPT entry head keeps for vTLB (TC could go away soon).
Limiting the entry to be not moved to VHPT head could solve this
issue but again the code will be complicated.
Sharing VTLB/VHPT memory could be simply used here, and the patch
will be more smaller and simple IMO.
>
>> To tell the truth, I rewrote the vtlb_thash() function before. See.
>>
http://lists.xensource.com/archives/html/xen-ia64-devel/2007-08/msg00108
.html
>>
>> I think the algorithm is the same as HW.
>> I did a reverse engineering on a Montecito processor.
>> (I'm afraid Montvale use the different algorithm...)
Could be in reality, I don't know :) But we still think it is different
since
we can;t guarante it is same :(
>
> This seems to be the same algorithm as the one for Madison. Cf
> Matthew Chapman pages.
>
> Tristan.
Thanks, eddie
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home