It depends. You can't tell only by looking at the addresses, you need to look at the mappings. If those virtual addresses you specified (00007f802b0ca100 and ffff880005e5b640) map to the same data, then the caches should service the request; yes.
I'd recommend looking at the symbols for the two addresses; ffff880005e5b640 is a kernel address so it's entirely possible that it corresponds to data that userspace has no business touching. You should be able to tell whether or not that's the case by looking up the symbol name in kallsyms and finding out it's use in the kernel's source code. Tyler > Thanks once again for your answers and attention. > > Through your welcome answers and studying the code of marss, i have > understood that in Marssx86 the implementation of caches is VIPT based . > However, i have observed that there are a *few cases* in which two > requests hit in the same cacheline but their corresponding accesses in > memory are made in different virtual addresses: (request A) > 00007f802b0ca100 and (request B) ffff880005e5b640. Concerning the > performance model that encounters hits and misses, is this a bug? > > > > vadd_in_line 00007f802b0ca100 first_word_virt_addr ffff880005e5b640 > > On 09/09/2014 05:15 PM, [email protected] wrote: >> I should also mention that this is just one scheme (not 'should use'). >> You >> could also use PIPT/VIVT (physically indexed, physically tagged or >> virtually indexed, virtually tagged caches). >> >> However, PIPT/VIVT have problems of their own. PIPT is really slow >> because >> you have to wait for the address translation to occur before you can >> start >> poking the caches. VIVT presents a lot of memory aliasing issues that >> need >> workarounds -- think about your context swapping example. >> >> VIPT caches are what most vendors are probably implementing now due to >> the >> tradeoff of consistency and access time, and will likely yield the best >> simulation results for modern architectures. >> >>> That's one possibility. Supposing we have a 512KiB cache, another is: >>> >>> Process A: >>> VA 0x00000 -> PA 0x1000 >>> >>> Process B: >>> VA 0x80000 -> PA 0x1000 >>> >>> Both could use different virtual addresses to index to the same cache >>> line, whose physical tag would then match. You'd need additional >>> mechanisms to protect against behavior like this, if it is not desired. >>> >>>> Dear Tyler thanks a lot for your reply. >>>> >>>> In the second case (it's a data from a page that gets mapped into all >>>> processes or something, in which case it's shared as expected) all the >>>> processes will use the same virtual address to access the memory? >>>> >>>> >>>> >>>> On 09/09/2014 03:31 PM,[email protected] wrote: >>>>> The caches should be physically tagged (though virtually indexed). >>>>> >>>>> The use of a physical tag guarantees that even if you index with a a >>>>> virtual address from another process's address space space, you will >>>>> likely see a physical tag mismatch (unless it's a data from a page >>>>> that >>>>> gets mapped into all processes or something, in which case it's >>>>> shared >>>>> as >>>>> expected). >>>>> >>>>> Tyler >>>>> >>>>>> Dear all, >>>>>> >>>>>> in the case of single core ooo model, how does the simulator ensure >>>>>> that >>>>>> different processes will not access the same cache line of in a >>>>>> Cache? >>>>>> >>>>>> In my knowledge, I would expect an invalidation of cache hierarchy >>>>>> whenever the executed process is changed or a way of process-id >>>>>> marking >>>>>> of each cache line. >>>>>> >>>>>> What do you think about? >>>>>> >>>>>> Sotiris Tselonis >>>>>> >>>>>> _____ > > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
