Nicolas, On Tue, Feb 13, 2007 at 01:04:31PM +0100, nicolas inglart wrote: > > Ok but if I put a lot of load independent instructions(more than > 600instructions) between two cache access , why data_ear_lat4 doesn't > change? > For example: > > The asm code: > > mov r1 = r32 > mov r15 = r0 > addl r16 = 99999, r0 > L7: > ;; > sxt4 r14 = r15 > adds r17 = 16, r12 > ;; > shladd r14 = r14, 2, r17 > ;; > ldfs f6 = [r14] (1) > ;; > fadd.s f6 = f6, f1(2) > ;; > stfs [r14] = f6 > adds r15 = 1, r15 > ;; > cmp4.ge p6, p7 = r16, r15 > (p6) br.cond.dptk .L7 > > I obtain: > 12376 DATA_EAR_CACHE_LAT4 > 100611 L2_DATA_REFERENCES_L2_DATA_READS > > with 600 independant instructions(mov r7 = r8;; for example) > i obtain the same result
One more thing is that the Data-EAR has an integrated randomizer such that it does not always pick the same loads. That may explain what you are seing. > --------------------------------------------------------- > Original message: > > > Nicolas, > > On Thu, Dec 21, 2006 at 04:00:46PM +0100, nicolas inglart wrote: > > Hi all, > > > > I don't understand why the value of the counter DATA_EAR_CACHE4 and the > counter L1D_READ_MISSES_ALL are different. > > > This is a good question. The answer is fairly simple. > > The DATA_EAR_CACHE_LAT4 event does not count ALL the L1D cache misses but > only the ones that are tracked by the Data-EAR. > The Data EAR does not track all L1D misses by construction. As you realize > once a load is selected to be tracked by the > Data EAR, no other load can be tracked until the Data EAR record is complete > i.e., until the miss latency is known which > happens when the missing data is brought into the L1D cache. During that > time, other loads in the "shadow" of the track > load may miss and they will be counted by L1D_READ_MISSES_ALL but not by > DATA_EAR_CACHE_*. So I would expect that > the DATA_EAR_CACHE_LAT4 count will always be lower or equal to > L1D_READ_MISSES_ALL. > > > Hope this helps. > > -- > -Stephane > > > -- > Ce message a été vérifié par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a été trouvé. > MailScanner remercie transtec pour son soutien. > > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
