Re: memory operation operand len

On Sat, Oct 20, 2012 at 1:14 PM, Xin Tong <[email protected]> wrote:
> On Sat, Oct 20, 2012 at 7:12 AM, Stanislav <[email protected]> wrote:
>> If you want to acquire lock for all locked instructions you need to read
the
>> lock (check if the lock is acquired) by all others, right ?
>> It looks me the same effort as locking a page for ever memory access
without
>> taking care if it is locked instruction or not ...
>>
>> For the page split instructions -  think you already saw that
>> read_virtual_yyy would call for read/write_access_linear function where
page
>> split is handled.
>> The function is already written in the way it checks for both pages
before
>> the read or write actually happens. So at least you can guarantee that no
>> need to unlock anything in case of a fault.
>>
>> Could you explain the way you wanna do these locks ?
>
>
> Right now every page is associated with a lock. before an atomic
> instruction is about to be executed. the executing CPU send
> async_events to all other CPUs to give up their translations to the
> physical page. after this is don, the executing CPU can safely acquire
> exclusive access to the page. and it will release the exclusive access
> when it is done with the atomic instruction. and if the atomic
> instruction access crosses pages, the exclusive access is acquired on
> the adjacent linear address page.
>
> Hope this answers your question.

I suspect this will perform badly in case of lock contended pages. i.e.
this will cause many async events being sent and CPUs interrupted often.
this interrupt has a direct and indirect cost.

direct cost - interrupted CPU exits and a re-lookup of next entry is needed.
indirect cost - new entries being built in the middle of a basic block as
the CPU exits in the middle of a basicblock.

I have not measure the amount of impact these have.

a possible improvement would be to promote lock contended pages to a
special type of page of which a lock needs to be acquired/release
before/after an instruction that is going to access the page.

i am thinking an extra check for contended pages can be added here

// Translate a linear address to a physical address
bx_phy_address BX_CPU_C::translate_linear(bx_address laddr, unsigned user,
unsigned rw)
{
  ,...
  // already looked up TLB for code access
  if (TLB_LPFOf(tlbEntry->lpf) == lpf)
  {
    paddress = tlbEntry->ppf | poffset;

*    // This is the meat of the TLB code. it uses the TLB to do fast
translation.
    if (! (tlbEntry->accessBits & ((isExecute<<2) | (isWrite<<1) | user)))
          return paddress;*
    // The current access does not have permission according to the info
    // in our TLB cache entry.  Re-walk the page tables, in case there is
    // updated information in the memory image, and let the long path code
    // generate an exception if one is warranted.
  }

....
}


Xin
>
> Xin
>
>
>>
>> Stanislav
>>
>> -----Original Message-----
>> From: Xin Tong [mailto:[email protected]]
>> Sent: Friday, October 19, 2012 10:37 PM
>> To: Stanislav
>> Cc: [email protected]
>> Subject: Re: [Bochs-developers] memory operation operand len
>>
>> i want to lock the page the atomic memory operation is going to work on .
>> this way atomic operations can be emulated correctly when the CPUs are
>> running in parallel.
>>
>> I happen to add function calls to acquire exclusive ownership of a page
just
>> before the atomic instruction is about to execute.
>>
>> In case of page fault, i think BOCHS returns to the CPU loop using
longjmp.
>> i  have code to release the exclusive ownership of the page there as
well.
>>
>> Xin
>>
>>
>> On Fri, Oct 19, 2012 at 3:27 PM, Stanislav <[email protected]> wrote:
>>> By reading the class bxInstruction_c you cannot know a thing,
>>> especially because some instructions access memory multiple times
>>> (FXSAVE, REP MOVS) or access variable amount of bytes (VMASKMOV).
>>>
>>> I am not talking about many memory access cases which not related to
>>> any instruction (page walks, descriptors reads and other system stuff).
>>>
>>> Also before the memory access actually happen an instruction might
>>> fault so the memory access won't happen.
>>>
>>> But what do you want to do ?
>>>
>>> Might be I can help ...
>>>
>>> If you searching to lock memory before memory access happens you can
>>> look for BX_NOTIFY_LIN_MEMORY_ACCESS and BX_NOTIFY_PHY_MEMORY_ACCESS
>>> all around the code.
>>>
>>> Stanislav
>>>
>>> -----Original Message-----
>>> From: Xin Tong [mailto:[email protected]]
>>> Sent: Friday, October 19, 2012 9:06 PM
>>> To: [email protected]
>>> Subject: [Bochs-developers] memory operation operand len
>>>
>>> what is the best way to figure out the length of the memory a memory
>>> operation is going to access in BOCHS ? I read the class
>>> bxInstruction_c. it does not seem to provide anything to do that ?
>>>
>>> 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
>>> _______________________________________________
>>> bochs-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/bochs-developers
>>>
>>

------------------------------------------------------------------------------
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

_______________________________________________
bochs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bochs-developers