Re: SMC for page crossing traces

On Wed, Oct 31, 2012 at 4:51 PM, Stanislav <[email protected]> wrote:
> Hi,
>
> This optimization is already long time in my mind but I had no time to try
> it and see the impact.

This may not be very impactful in the current BOCHS states as
interpreter is slow and the benefit gained from having this would be
minimal. However, if a JIT is implemented later. The benefit would be
clear as calling decWritStamp on every write instruction would be
relatively expensive. on obvious thing is this will increase the size
of the JITed code ... With a JIT, if this optimization is in place,
the JIT will just need to exit the current JIT trace if TLB miss
happens. Otherwise it runs full speed ...

>
> The positive side is trivial - it would eliminate a need to decWriteStamp
> for all writes which do not share code in the same 4K page.
> But the other hand, when false sharing occurs (data and code are located in
> the same page) - the emulation performance will be terrible because all
> stores would have to go slow path.
> And not only stores, also code fetches ...
> We have observed huge amount of false sharing in Win95/98 and also not so
> small amount in WinXP code.
> Making SMC fine grained (128-byte granularity) had really visible impact on
> Windows boot emulation performance.
>
> Need to check if gain from all the "good" stores is bigger than loss from
> false sharing cases and see which one is better.
>
> As possible solution Darek suggested to implement L0TLB where an "entry" has
> a 128-byte length "pages" only with all attributes as for normal 4K pages.
> This way code crossing 128-byte boundary will be considered sort of "page
> split" and need to be treated special way.
> But from other hand your idea could be implemented on lower than 4K
> granularity and avoid false sharing problem.
>
> Another issue to consider here - multiprocessor. The pageWriteStamp table is
> unified while TLB is per-processor.
> So fetch from a page in one processor would cause chain of TLB invalidation
> on all others. This problem doesn't exists if emulating single CPU only.
>

This would not be a problem as the x86 TLB has to be shoot-down
explicitly. it is not invalidated automatically i think. when the page
table is modified. the modifying processor will have to issue IPI to
all other processors to have the stale TLB invalidated and this is
implemented in BOCHS already i think. :)

> Not sure I will have time to deal with it soon anyway ... would you like to
> try to provide a patch ?
>
> Stanislav
>
> -----Original Message-----
> From: Xin Tong [mailto:[email protected]]
> Sent: Wednesday, October 31, 2012 5:21 PM
> To: Stanislav
> Cc: [email protected]
> Subject: Re: [Bochs-developers] SMC for page crossing traces
>
> another optimization for SMC is not to installed pages that have code
> translated from into the TLB with write permission. later a write will miss
> the TLB and BOCHS can take a longer path to handle that (i.e.
> call decWriteStamp). this will eliminate the need to call decWriteStamp on
> every write.
>
> Xin
>
>
> On Thu, Oct 25, 2012 at 1:23 AM, Stanislav <[email protected]> wrote:
>> Yes, it is already changes in SVN. Including few more observations
>> that you didn't see yet .
>>
>>
>>
>> Unfortunately SVN services are not available right now for Bochs.
>> Might be you could look on latest SVN snapshot that Volker put on the
> Bochs webpage.
>>
>>
>>
>> Stanislav
>>
>>
>>
>> From: Xin Tong [mailto:[email protected]]
>> Sent: Thursday, October 25, 2012 1:01 AM
>> To: [email protected]
>> Subject: [Bochs-developers] SMC for page crossing traces
>>
>>
>>
>> I am reading this code and wondering why the entry is not invalidated
>> when the second part of the trace is written into.
>>
>>
>>
>>  if (mask & 0x1) {
>>
>>     // the store touched 1st cache line in the page, check for
>>
>>     // page split traces to invalidate.
>>
>>     for (i=0;i<BX_ICACHE_PAGE_SPLIT_ENTRIES;i++) {
>>
>>       if (pAddr == pageSplitIndex[i].ppf) {
>>
>>         pageSplitIndex[i].ppf = BX_ICACHE_INVALID_PHY_ADDRESS;
>>
>>         // SHOULD pageSplitIndex[i].e BE INVALIDATED HERE?
>>
>>       }
>>
>>     }
>>
>>   }
>>
>>
>>
>> Xin
>>
>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct