Hello Andreas, Now i understand.
Thanks, Prathap On Mon, Jul 27, 2015 at 4:49 AM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > When you write with a granularity smaller than a cache line (to your L1 > D cache), the cache will read the line in exclusive state, and then write > the specified part. If you write a whole line, then there is no need to > first read. The latter behaviour is supported for whole-line write > operations only. > > Andreas > > From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap > Kolakkampadath <kvprat...@gmail.com> > Reply-To: gem5 users mailing list <gem5-users@gem5.org> > Date: Tuesday, 21 July 2015 23:14 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Handling write backs > > Hello Users, > > I figured out that the Gem5 implements fetch-on-write-miss policy. > On a write miss, allocateMissBuffer() is called to allocate an MSHR ; > which send the timing request to bring this cache line. > Once the request is ready, in the response path, handleFill() is called, > which is responsible to insert the block in to the cache. While inserting, > if the replacing victim block is dirty;a write back packet is generated > and is copied to write buffers. > After which satisfyCpuSideRequest() is called to write the data to the > newly assigned block and marks it as dirty. > > Thanks, > Prathap > > > > > > > On Tue, Jul 21, 2015 at 11:21 AM, Prathap Kolakkampadath < > kvprat...@gmail.com> wrote: > >> Hello Users, >> >> I am using classic memory system. What is the write miss policy >> implemented in Gem5? >> Looking at the code it looks like, gem5 implements >> *no-fetch-on-write-miss* policy; the access() inserts a block in cache, >> when the request is writeback and it misses the cache. >> However, when i run a test with bunch of write misses, i see equal >> number of reads and writes to DRAM memory. This could happen if the policy >> is >> *fetch-on-write-miss.* So far i couldn't figure this out. It would be >> great if someone can throw some pointers to understand this further. >> >> Thanks, >> Prathap >> >> On Mon, Jul 20, 2015 at 2:02 PM, Prathap Kolakkampadath < >> kvprat...@gmail.com> wrote: >> >>> Hello Users, >>> >>> I am running a test which generate write misses to LLC. I am looking >>> at the cache implementation code. What i understood is, write are treated >>> as write backs; on miss, write back commands allocate a new block in cache >>> and write the data into it and marks this block as dirty. When the dirty >>> blocks are replaced,these will be written in to write buffers. >>> >>> I have following questions on this: >>> 1) When i run the test which generates write misses, i see same >>> number of reads from memory as the number of writes. Does this mean, write >>> backs also fetches the cache-line from main memory? >>> >>> 2) When the blocks in write buffers will be written to memory? Is it >>> written when the write buffers are full? >>> >>> It would be great if someone can help me in understanding this. >>> >>> >>> Thanks, >>> Prathap >>> >>> >> > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
