|
From: Balaji Rs I. <bri...@un...> - 2003-10-29 00:41:40
|
Hi, I was wondering if there is a way to use either cachegrind or valgrind or any other skin to determine what part of the memory is cached at a given time. This is what I would like it to do: a. given a range of memory, tell me how many references within that range are cached b. if this information could be runtime thanks regards -Balaji |
|
From: Balaji Rs I. <bri...@un...> - 2003-10-29 01:20:52
|
hi, This is a followup to my previous mail on cachegrind. Another way of putting my question is: is there a way to seggregate cache misses/hits depending on the address space in the memory i.e given an address range what percentage of cache misses/hits are attributable to this address range. thanks regards -Balaji |
|
From: Nicholas N. <nj...@ca...> - 2003-10-29 08:29:21
|
On Tue, 28 Oct 2003, Balaji Rs Iyengar wrote: > is there a way to seggregate cache misses/hits depending on the address > space in the memory i.e given an address range what percentage of cache > misses/hits are attributable to this address range. No, but it wouldn't be too hard to augment Cachegrind with another data structure to do this. The cache simulation stuff is in cachegrind/cg_sim_gen.c, and shouldn't be too hard to understand. N |
|
From: Balaji I. <bri...@nc...> - 2003-11-03 08:46:33
|
Hello,
i am trying to modify cachgrind so it tells me the percentage of hits and
misses attributable to a particular address range. I went through the code
in cg_sim_gen.c and cg_main.c and have the following questions.
1. #define CACHESIM(L, MISS_TREATMENT)
this macro is defined in cg_sim_gen.c and I am not able to determine
where it is used
2. the function: void cachesim_##L##_doref(Addr a, UChar size, ULong* m1,
ULong *m2)
is defined as part of the above macro, how is the ##L## translated to _I1_
and _D1_
3. If I have to make cachegrind except more command line arguments such as
the starting address and range, wher would i make these changes.
4. Also what would help is a general description of the sequence in which the
functions are called, because at this point I am totally at bay and dont
quite understand what is happening where in the code.
5. Could somebody highlight a brief set of steps that is required to do this
sort of thing (seggregate cache misses/hits depending on the address space in
the memory )
thanks a bunch
regards
-Balaji.
Nicholas Nethercote wrote:
> On Tue, 28 Oct 2003, Balaji Rs Iyengar wrote:
>
> > is there a way to seggregate cache misses/hits depending on the address
> > space in the memory i.e given an address range what percentage of cache
> > misses/hits are attributable to this address range.
>
> No, but it wouldn't be too hard to augment Cachegrind with another data
> structure to do this. The cache simulation stuff is in
> cachegrind/cg_sim_gen.c, and shouldn't be too hard to understand.
>
> N
|
|
From: Tom H. <th...@cy...> - 2003-11-03 09:06:54
|
In message <3FA...@nc...>
Balaji Iyengar <bri...@nc...> wrote:
> 2. the function: void cachesim_##L##_doref(Addr a, UChar size, ULong* m1,
> ULong *m2)
> is defined as part of the above macro, how is the ##L## translated to _I1_
> and _D1_
Well ## is the preprocessor's token pasting operator which can be
used for pasting token fixed tokens and macro arguments without any
whitespace being added in between.
So the macro expansion will effectively replace ##L## with the value
of the L argument to the macro.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-03 11:25:41
|
On Mon, 3 Nov 2003, Balaji Iyengar wrote:
> i am trying to modify cachgrind so it tells me the percentage of hits and
> misses attributable to a particular address range. I went through the code
> in cg_sim_gen.c and cg_main.c and have the following questions.
>
> 1. #define CACHESIM(L, MISS_TREATMENT)
> this macro is defined in cg_sim_gen.c and I am not able to determine
> where it is used
[~/grind/head5/cachegrind] grep CACHESIM *.c
cg_sim_D1.c:CACHESIM(D1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
cg_sim_gen.c:#define CACHESIM(L, MISS_TREATMENT) \
cg_sim_I1.c:CACHESIM(I1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
cg_sim_L2.c:CACHESIM(L2, (*m2)++ );
> 2. the function: void cachesim_##L##_doref(Addr a, UChar size, ULong* m1, ULong *m2)
> is defined as part of the above macro, how is the ##L## translated to _I1_ and _D1_
As Tom said, it's macro concatenation.
> 3. If I have to make cachegrind except more command line arguments such as
> the starting address and range, wher would i make these changes.
Look for variables named "clo_*" and "VG_(clo_*)" in the skins (eg.
Cachegrind, Memcheck) for example usage. They're fairly straightforward.
> 4. Also what would help is a general description of the sequence in which the
> functions are called, because at this point I am totally at bay and dont
> quite understand what is happening where in the code.
Which functions?
First of all, have you read the skin-writing guide? (Section 7 of the
manual).
Once you've done that, I would try modifying Cachegrind in very small
steps. Start by just inserting printf's in strategic places to work out
when different things occur.
However, I think for what you want, all you need is to adjust the
cachesim_##L##_doref function -- because you don't want to change how the
addresses accessed are passed to the cache simulation, but rather what's
done with those addresses within the simulation. You don't need to know
how Cachegrind is finding those addresses. But I can understand that you
might want to know how it does it.
> 5. Could somebody highlight a brief set of steps that is required to do this
> sort of thing (seggregate cache misses/hits depending on the address space in
> the memory )
It seems there's two parts to your problem. The first is getting the
stream of address reads and writes. The second is using them to simulate
the cache. Segregating the memory falls under the second, and shouldn't
be hard -- instead of having single global counters for hit and miss
counts, have a series of them, one per address range.
Hope this helps.
N
|
|
From: Balaji Rs I. <bri...@un...> - 2003-12-08 05:02:17
|
hi,
I am trying to seggregate the percentage of hits and misses attributable
to a particular address range. To be precise I am running some bench marks
on a Java Virtual machine, for e.g.:
valgrind --skin=cachegrind --I1=8192,8,64 --D1=8192,8,64 --L2=262144,8,64 rvm -X:gc:verbose=4 SpecApplication _200_check
I modified the cachesim_##L##_doref function and added a data structure
to get the miss and hit counts to specific areas in the heap.
The range of addresses I am interested in, is the heap space maintained by
the JavaVM. A -v command line flag in the VM tells me these address ranges
and I use these to do the conditional checks in the cachesim_##L##_doref
function followed by the counter increments in case of misses and hits.
However from the counter values and the out file generated it is
apparent that none of the addresses passed to cache-grind are in this
range. This is not possible since these addresses are being accessed by
the Java VM. This leads me to think that this is because of the address
translation being done by valgrind.
My questions are:
1. Could you explain where this address translation is done. I looked into
the detailed tech notes and went through the code in vg_memory.c and I
have some understanding but I am not clear.
2. Given an address range A-B, is there a way to determine the range to
which this will be translated by valgrind.
Any additinol pointers will be greatly appreciated.
thanks
best regards
-balaji.
On Mon, 3 Nov 2003, Nicholas Nethercote wrote:
> On Mon, 3 Nov 2003, Balaji Iyengar wrote:
>
> > i am trying to modify cachgrind so it tells me the percentage of hits and
> > misses attributable to a particular address range. I went through the code
> > in cg_sim_gen.c and cg_main.c and have the following questions.
> >
> > 1. #define CACHESIM(L, MISS_TREATMENT)
> > this macro is defined in cg_sim_gen.c and I am not able to determine
> > where it is used
>
> [~/grind/head5/cachegrind] grep CACHESIM *.c
> cg_sim_D1.c:CACHESIM(D1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
> cg_sim_gen.c:#define CACHESIM(L, MISS_TREATMENT) \
> cg_sim_I1.c:CACHESIM(I1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
> cg_sim_L2.c:CACHESIM(L2, (*m2)++ );
>
>
> > 2. the function: void cachesim_##L##_doref(Addr a, UChar size, ULong* m1, ULong *m2)
> > is defined as part of the above macro, how is the ##L## translated to _I1_ and _D1_
>
> As Tom said, it's macro concatenation.
>
> > 3. If I have to make cachegrind except more command line arguments such as
> > the starting address and range, wher would i make these changes.
>
> Look for variables named "clo_*" and "VG_(clo_*)" in the skins (eg.
> Cachegrind, Memcheck) for example usage. They're fairly straightforward.
>
> > 4. Also what would help is a general description of the sequence in which the
> > functions are called, because at this point I am totally at bay and dont
> > quite understand what is happening where in the code.
>
> Which functions?
>
> First of all, have you read the skin-writing guide? (Section 7 of the
> manual).
>
> Once you've done that, I would try modifying Cachegrind in very small
> steps. Start by just inserting printf's in strategic places to work out
> when different things occur.
>
> However, I think for what you want, all you need is to adjust the
> cachesim_##L##_doref function -- because you don't want to change how the
> addresses accessed are passed to the cache simulation, but rather what's
> done with those addresses within the simulation. You don't need to know
> how Cachegrind is finding those addresses. But I can understand that you
> might want to know how it does it.
>
> > 5. Could somebody highlight a brief set of steps that is required to do this
> > sort of thing (seggregate cache misses/hits depending on the address space in
> > the memory )
>
> It seems there's two parts to your problem. The first is getting the
> stream of address reads and writes. The second is using them to simulate
> the cache. Segregating the memory falls under the second, and shouldn't
> be hard -- instead of having single global counters for hit and miss
> counts, have a series of them, one per address range.
>
> Hope this helps.
>
> N
>
|