|
From: Florian K. <br...@ac...> - 2012-08-27 03:48:17
|
I'd like to auto-detect the cache configuration of the host machine for
s390. So I was looking around how this is done on other architectures.
Turns out, nobody does it except x86 and x86-64. These architectures get
special treatment in form of VG_(cpuid). But that function is not
portable to other architectures. On s390 I would need to know whether
the host supports a certain insn. That info is present in the "hwcaps"
field of VexArchInfo. But VexArchInfo is not passed to the tools.
Now what? I see two approaches.
(1) Pass VexArchInfo to the "instrument" function of the tool. That
structure would convey whether or not the cache configuration of
the host can be queried. A tool would then query that information
in an architecture-specific way. For instance, we could amend
VexArchInfo by adding a "Bool x86_amd64_has_cpuid" field. Cachegrind
would then call VG_(cpuid) if that field is True. VG_(has_cpuid)
would be obsolete.
(2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return
information about the host's caches in a general way:
- number of cache levels
- for each cache level
- split data/insn cache or not
- line size
- cache size
- set associativity
Also replace VG_(has_cpuid) with VG_(has_cache_info).
So #2 moves all the architecture specific machinery for querying out of
the tools. It concentrates it in a single spot. Which is nice, should
there ever be more than one tool wanting that info. There is a bit of
work to provide the cache info in this proposed form, but I presume it
shouldn't be difficult to do.
#1 is of course less implementation work.
I do not have a strong preference either way. #2 seems to be the better
approach for the long term. But we can bite the bullet at the time when
another tool emerges which needs to know this stuff and for now just run
with #1 (which is what I would do).
Opinions, strong and otherwise are welcome.
Florian
|
|
From: John R. <jr...@bi...> - 2012-08-27 04:24:37
|
> (2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return > information about the host's caches in a general way: > - number of cache levels > - for each cache level > - split data/insn cache or not > - line size > - cache size > - set associativity Cache policies can be important, too: Action taken upon a miss (read miss allocate? write miss allocate?), replacement algorithm (selecting a victim), interleaving algorithm (map from virtual address to cache set/line), number of levels traversed by a fill, auto pre-fetch (AltiVec, etc.), coherency, coloring (small page size (< 64KB) creates big problems), ... -- |
|
From: Julian S. <js...@ac...> - 2012-08-28 18:24:30
|
On Monday, August 27, 2012, Florian Krohm wrote:
> I'd like to auto-detect the cache configuration of the host machine for
> s390. So I was looking around how this is done on other architectures.
> Turns out, nobody does it except x86 and x86-64. These architectures get
> special treatment in form of VG_(cpuid). But that function is not
> portable to other architectures. On s390 I would need to know whether
> the host supports a certain insn. That info is present in the "hwcaps"
> field of VexArchInfo. But VexArchInfo is not passed to the tools.
The design philosophy (which may be flawed, but anyway) is that tools
really only need to be able to analyse and generate IR. They don't need
to be aware of the details of the architecture/cpu under simulation.
We abuse that wildly in Callgrind and Cachegrind, by allowing tools
to make their own attempts to establish the cache parameters. But I
would prefer not to perpetuate this abstraction-breakage by passing
VexArchInfo to tools.
And it doesn't make much sense for Callgrind/Cachegrind to have their
own CPU-querying code in
cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
when we already have a centralised facility to generally poke around
the host cpu and figure out what it can do, in coregrind/m_machine.c.
Overall, a cleanish refactoring seems to me to be to merge
cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
and have a new function, VG_(machine_get_cacheinfo) (as a peer
of VG_(machine_get_hwcaps)), that tools can call if they want
to get cache info. Then we could nuke VG_(has_cpuid) and also
write VG_(cpuid) using inline assembly, hence getting rid of
m_cpuid.S entirely.
None of which helps you in the short term, since it's quite a lot
of work to do that refactoring. The difficulty (and hence the
delay in reply to this msg) is that I'm not enthusiastic about
either (1) or (2) below.
How much refactoring effort are you prepared to go to at this point?
I wonder if there's a way to get you what you want without too much
effort, whilst at the same time moving incrementally in the
direction of centralising cache detection stuff in coregrind.
J
> Now what?
> (1) Pass VexArchInfo to the "instrument" function of the tool. That
> structure would convey whether or not the cache configuration of
> the host can be queried. A tool would then query that information
> in an architecture-specific way. For instance, we could amend
> VexArchInfo by adding a "Bool x86_amd64_has_cpuid" field. Cachegrind
> would then call VG_(cpuid) if that field is True. VG_(has_cpuid)
> would be obsolete.
>
> (2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return
> information about the host's caches in a general way:
> - number of cache levels
> - for each cache level
> - split data/insn cache or not
> - line size
> - cache size
> - set associativity
> Also replace VG_(has_cpuid) with VG_(has_cache_info).
|
|
From: Florian K. <br...@ac...> - 2012-08-29 00:17:56
|
On 08/28/2012 02:23 PM, Julian Seward wrote:
> And it doesn't make much sense for Callgrind/Cachegrind to have their
> own CPU-querying code in
> cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
> when we already have a centralised facility to generally poke around
> the host cpu and figure out what it can do, in coregrind/m_machine.c.
>
> Overall, a cleanish refactoring seems to me to be to merge
> cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
> and have a new function, VG_(machine_get_cacheinfo) (as a peer
> of VG_(machine_get_hwcaps)), that tools can call if they want
> to get cache info. Then we could nuke VG_(has_cpuid) and also
> write VG_(cpuid) using inline assembly, hence getting rid of
> m_cpuid.S entirely.
That is essentially, what I had in mind with (2) below which also calls
for VG_(cpuid) to be replaced with a function that provides the cache
info for all architectures. I guess, I did not make that clear enough.
>
> None of which helps you in the short term, since it's quite a lot
> of work to do that refactoring.
True. That is why I wanted to sneak in VexArchInfo.. :)
> How much refactoring effort are you prepared to go to at this point?
Limited. There is a larger patch pending from Christian that I need to
look at first.
> I wonder if there's a way to get you what you want without too much
> effort, whilst at the same time moving incrementally in the
> direction of centralising cache detection stuff in coregrind.
Incremental is good. We could do this:
(1) define the API and the data structure to represent a cache
(2) do the s390 implementation for it
(3) make cachegrind/cg-s390x.c use it
(4) fold VG_(cpuid) under the new API
(5) reorg cachegrind to use the new API; eliminate
cachegrind/cg-<arch>.c
Florian
>>
>> (2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return
>> information about the host's caches in a general way:
>> - number of cache levels
>> - for each cache level
>> - split data/insn cache or not
>> - line size
>> - cache size
>> - set associativity
>> Also replace VG_(has_cpuid) with VG_(has_cache_info).
>
|
|
From: Maynard J. <may...@us...> - 2012-08-29 13:42:49
|
On 08/28/2012 07:17 PM, Florian Krohm wrote:
> On 08/28/2012 02:23 PM, Julian Seward wrote:
>
>> And it doesn't make much sense for Callgrind/Cachegrind to have their
>> own CPU-querying code in
>> cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
>> when we already have a centralised facility to generally poke around
>> the host cpu and figure out what it can do, in coregrind/m_machine.c.
>>
>> Overall, a cleanish refactoring seems to me to be to merge
>> cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
>> and have a new function, VG_(machine_get_cacheinfo) (as a peer
>> of VG_(machine_get_hwcaps)), that tools can call if they want
>> to get cache info. Then we could nuke VG_(has_cpuid) and also
>> write VG_(cpuid) using inline assembly, hence getting rid of
>> m_cpuid.S entirely.
>
> That is essentially, what I had in mind with (2) below which also calls
> for VG_(cpuid) to be replaced with a function that provides the cache
> info for all architectures. I guess, I did not make that clear enough.
>
>>
>> None of which helps you in the short term, since it's quite a lot
>> of work to do that refactoring.
>
> True. That is why I wanted to sneak in VexArchInfo.. :)
>
>> How much refactoring effort are you prepared to go to at this point?
>
> Limited. There is a larger patch pending from Christian that I need to
> look at first.
>
>> I wonder if there's a way to get you what you want without too much
>> effort, whilst at the same time moving incrementally in the
>> direction of centralising cache detection stuff in coregrind.
>
> Incremental is good. We could do this:
> (1) define the API and the data structure to represent a cache
> (2) do the s390 implementation for it
> (3) make cachegrind/cg-s390x.c use it
> (4) fold VG_(cpuid) under the new API
> (5) reorg cachegrind to use the new API; eliminate
> cachegrind/cg-<arch>.c
Florian,
Adding support for auto-detection of cache config for ppc64 has been on my todo list for a while. Either Carl or I should have some time available to help out with this effort. Please keep me in the loop for the API definition conversation.
-Maynard
>
> Florian
>
>
>>>
>>> (2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return
>>> information about the host's caches in a general way:
>>> - number of cache levels
>>> - for each cache level
>>> - split data/insn cache or not
>>> - line size
>>> - cache size
>>> - set associativity
>>> Also replace VG_(has_cpuid) with VG_(has_cache_info).
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|