Re: [Gems-users] Does gems (ruby) model the DMA operations now?

[Polina Dudnik <pdudnik@xxxxxxxxx>]

Are you 100% sure you actually have DMA requests on your benchmark?

On Sat, Dec 19, 2009 at 1:35 PM, Sitos Lin <sitos.lin@xxxxxxxxx> wrote:

Hi:
 Thank you for this. The information is very useful for me. I tried
to modify the functions: makeRequest and isUnhandledTransaction in
SimicsDriver.C to output the DMA information, but there is no
response. I still get the cache stats as uaual, but I can not output
any message from the functions. I even tried to add exit(0) in the
functions, but the program finish normally. I followed the compilation
instructions and other functions work normally. I have no idea about
what is wrong. Could anyone give me some hints? Maybe the new compiled
module does not connect to Simics/Opal or the functions are never
called.
Best regards,
 Sitos

2009/12/19 Muhammad abid Mughal <mabidm_pieas@xxxxxxxxx>:
> Hi,
>  Is gems aware this? yes
>  If you are using Simics and Ruby then for every memory operation(ie
> ld/st/atomic/ifetch/prefetch/dma/io, etc)  simics calls this function
>     SimicsDriver::makeRequest() and this function filters out all
> unsupported operations(ie i/o , DMA,cache flush, prefetch)
> via  SimicsDriver::isUnhandledTransaction(). so this way DMA/ io operations
> are not passed to Ruby and not cached in any caches.
> Do you have any idea about how to know where are the I/O blocks?
> you need to make some changes to this function
> SimicsDriver::isUnhandledTransaction(). whenever memory is accessed by DMA
> or I/O device this
> IS_DEV_MEM_OP(mem_trans->s.ini_type) returns true and you can use
> 'mem_trans' arg to do some profiling
> Hope it helps
> Regards,
> Muhammad abid
> ________________________________
> From: Sitos Lin <sitos.lin@xxxxxxxxx>
> To: Gems Users <gems-users@xxxxxxxxxxx>
> Sent: Saturday, December 19, 2009 14:52:44
> Subject: Re: [Gems-users] Does gems (ruby) model the DMA operations now?
>
> Hello:
>   You said that " DMA accesses I/O blocks and Ultrasparc processor
> does not allow caching of I/O blocks". Is gems aware this? If the I/O
> blocks are uncacheable, maybe I can gather the memory accesses
> correspondent to DMA operations by monitoring the memory accesses
> belong to I/O blocks by knowing the memory range of I/O blocks. Do you
> have any idea about how to know where are the I/O blocks? Thank you.
> Best regards,
>   Sitos
>
> 2009/12/18 Muhammad abid Mughal <mabidm_pieas@xxxxxxxxx>:
>> hi
>> I do know that Ruby does not support DMA requests even in gems-2.1. It
>> just
>> filters them out via SimicsDriver::isunhandledtransaction(), so its not
>> possible for DMA requests to invalidate the corresponding cache blocks in
>> L1/L2 caches[i am wondering that DMA accesses I/O blocks and Ultrasparc
>> processor does not allow caching of i/o blocks, so no question of
>> invalidating corresponding L1$/L2$ blocks.am i right?]
>> Regards,
>> Muhammad abid
>> ________________________________
>> From: Sitos Lin <sitos.lin@xxxxxxxxx>
>> To: gems-users@xxxxxxxxxxx
>> Sent: Friday, December 18, 2009 11:24:41
>> Subject: [Gems-users] Does gems (ruby) model the DMA operations now?
>>
>> Hello all:
>>   I want to use gems (ruby) to capture the memory access trace.
>> However, I am wondering if gems models the DMA operations. In the
>> paper, it says "Also, Ruby does not model the memory system traffic
>> due to direct memory access (DMA) operations or memory-mapped I/O
>> loads and stores." However, gems is now version 2.1. Does gems model
>> the DMA operations now?
>>   Besides that, if the memory system traffic of DMA operations are not
>> modeled, I want to know if DMA operations invalidate the correspondent
>> cache blocks in L1/L2 caches. Since the values of memory have been
>> changed by DMA (read) operations, the cache blocks should be
>> invalidated and the following cache accesses to these lines should be
>> miss. I have tried to test gems by two simple program. However, the
>> results are not consistent to my knowledge. The program with
>> additional DMAs causes less cache misses than another one without DMA
>> operation.
>>   If gems can not model the features mentioned above, I will try other
>> approaches.
>> Best regards,
>>   Sitos

>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by adding
>> "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>>
>>

>> ________________________________
>> New Email addresses available on Yahoo!
>> Get the Email name you've always wanted on the new @ymail and @rocketmail.
>> Hurry before someone else does!

>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by adding
>> "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>>
>>
>>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>
>

> ________________________________
> New Email names for you!
> Get the Email name you've always wanted on the new @ymail and @rocketmail.
> Hurry before someone else does!

> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>
>
>
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.