Re: memory operation operand len

>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 >done, 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.

Writing to a page exclusively is very nice idea and I already could think of
possible optimization for it.

Each atomic instruction is actually Read-Modified-Write were you need to
guarantee that nobody wrote to the same location before the read and the
write belonging to the same atomic instruction. 
So you only need to protect against writes from another threads.
But every write in Bochs does ne extra  operation - it consults
pageWriteStampTable for SMC detection.
In the pageWriteStampTable stored metadata per 4K page, t is possible to add
to the metadata thread number which has exclusive write access to a page.
Then if you already hold the page (pageWriteStampTable.pageOwner = you) you
could safely write without broadcasting async_event.
If the page does not belong to you - you send the async_event (even no need
to everybody, only for current owner) wait until owner is stopped and then
change page ownership and write.

So:

a) reads don't care
b) if nobody touches your page - no perf impact

About page split locks - you should not care.
There are no real life application which would have page split locks.
Split locks (even cache line split locks) are painful in all modern
processors, all CPUs starting from Pentium acquired bus for exclusive access
in order to execute split lock (bus lock transaction).
Doing bus lock on modern multicore processor might take up to 100000 CPU
cycles, this is so huge that you won't see them in any application.
You could PANIC for now in your code for any split lock - it will work well
enough !

Stanislav

-----Original Message-----
From: Xin Tong [mailto:[email protected]] 
Sent: Saturday, October 20, 2012 7:14 PM
To: Stanislav
Cc: [email protected]
Subject: Re: [Bochs-developers] memory operation operand len

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.

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