From: William Cohen <wcohen@redhat.com>
To: eranian@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, perfctr-devel@lists.sourceforge.net,
perfmon@napali.hpl.hp.com, linux-kernel@vger.kernel.org,
oprofile-list@lists.sourceforge.net
Subject: Re: [Perfctr-devel] [perfmon] 2.6.17.1 new perfmon code base, libpfm,
Date: Mon, 26 Jun 2006 17:10:53 +0000 [thread overview]
Message-ID: <44A0151D.5090400@redhat.com> (raw)
In-Reply-To: <20060623212354.GA1102@frankl.hpl.hp.com>
Stephane Eranian wrote:
> Will,
>
> On Fri, Jun 23, 2006 at 05:13:47PM -0400, William Cohen wrote:
>
>>Hi Stephane,
>>
>>Some quick questions about the current perfmon code.
>>
>>
>>The athlon has very similar hw to the amd64 and there is now 32-bit
>>x86-64 support. Wouldn't it make sense to move perfmon_amd.c to i386
>>and have it work in the same way as perfmon_p4.c does currently for p4
>>and em64t?
>>
>
> Does Athlon have 4 counters as well. I don't have the HW so I cannot really
> test. I suspect they are similar. If you have HW and you can test, I don't
> have a problem.
I have an Athlon machine in the office that I can test this change out
on and send you a diff.
>>Could the 32-bit and 64-bit code be combined in a manner similar to
>>oprofile and avoid duplication between perfmon_em64t_pebs.c and
>>perfmon_p4_pebs.c? pfm_{p4|em64}_ds_area and
>>pfm_{p4|em64t}_pebs_sample_entry have differences due to the upgrade
>>from 32 to 64 bit values.
>>
>
> You have several issues here:
> - the 64-bit version has 8 more reigsters int the PEBS entry
> - the PEBS entry uses 32 or 64 bitfields depending on data model
> - the ds_area uses 32 or 64 bits depending on the data model except for the threshold value
>
> Now remember that on on EM64T we also support 32-bit (i386) binaries.
> With an EM64T kernel you would have the 64-bit PEBS format. With the same UUID if would satisfy
> a i386 binary and this is wrong because they would not match the definition of the PEBS entry.
> We need to keep the PEBS 32 and 64-bit format UUIDs different. At the source code level, you would
> need to ifdef __x86_64__ and __i386__ to switch struct definition and UUID. That's doable but is
> this clean?
Certainly given the differences in the pebs elements there will need to
unique names for each. It was just a thought to factor out the similar code.
There is support to handle amd64 hardware running on 32-bit kernel. Has
someone verified that the em64t processor generate 32-bit compatible
entries when running in 32-bit mode? Or does it always write out 64-bit
style PEBS entries?
>>Why isn't Intel family 0xf model 3 not supported?
>> Model 1,2, 4, and 5 are supported.
>> Model 3 Pentium4 isn't that different is it?
>
>
> I have not looked at this. I don't have a lot of P4 HW. I think that
> all family 15 uses the same PMU. Could someone confirm this?
A NC State University professor mentioned that the ommission of model 3
was a problem because his machine were model 3. I suggested the addition
of case for model 3 processors to get him going on that.
-Will
WARNING: multiple messages have this Message-ID (diff)
From: William Cohen <wcohen@redhat.com>
To: eranian@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, perfctr-devel@lists.sourceforge.net,
perfmon@napali.hpl.hp.com, linux-kernel@vger.kernel.org,
oprofile-list@lists.sourceforge.net
Subject: Re: [Perfctr-devel] [perfmon] 2.6.17.1 new perfmon code base, libpfm, pfmon available
Date: Mon, 26 Jun 2006 13:10:53 -0400 [thread overview]
Message-ID: <44A0151D.5090400@redhat.com> (raw)
In-Reply-To: <20060623212354.GA1102@frankl.hpl.hp.com>
Stephane Eranian wrote:
> Will,
>
> On Fri, Jun 23, 2006 at 05:13:47PM -0400, William Cohen wrote:
>
>>Hi Stephane,
>>
>>Some quick questions about the current perfmon code.
>>
>>
>>The athlon has very similar hw to the amd64 and there is now 32-bit
>>x86-64 support. Wouldn't it make sense to move perfmon_amd.c to i386
>>and have it work in the same way as perfmon_p4.c does currently for p4
>>and em64t?
>>
>
> Does Athlon have 4 counters as well. I don't have the HW so I cannot really
> test. I suspect they are similar. If you have HW and you can test, I don't
> have a problem.
I have an Athlon machine in the office that I can test this change out
on and send you a diff.
>>Could the 32-bit and 64-bit code be combined in a manner similar to
>>oprofile and avoid duplication between perfmon_em64t_pebs.c and
>>perfmon_p4_pebs.c? pfm_{p4|em64}_ds_area and
>>pfm_{p4|em64t}_pebs_sample_entry have differences due to the upgrade
>>from 32 to 64 bit values.
>>
>
> You have several issues here:
> - the 64-bit version has 8 more reigsters int the PEBS entry
> - the PEBS entry uses 32 or 64 bitfields depending on data model
> - the ds_area uses 32 or 64 bits depending on the data model except for the threshold value
>
> Now remember that on on EM64T we also support 32-bit (i386) binaries.
> With an EM64T kernel you would have the 64-bit PEBS format. With the same UUID if would satisfy
> a i386 binary and this is wrong because they would not match the definition of the PEBS entry.
> We need to keep the PEBS 32 and 64-bit format UUIDs different. At the source code level, you would
> need to ifdef __x86_64__ and __i386__ to switch struct definition and UUID. That's doable but is
> this clean?
Certainly given the differences in the pebs elements there will need to
unique names for each. It was just a thought to factor out the similar code.
There is support to handle amd64 hardware running on 32-bit kernel. Has
someone verified that the em64t processor generate 32-bit compatible
entries when running in 32-bit mode? Or does it always write out 64-bit
style PEBS entries?
>>Why isn't Intel family 0xf model 3 not supported?
>> Model 1,2, 4, and 5 are supported.
>> Model 3 Pentium4 isn't that different is it?
>
>
> I have not looked at this. I don't have a lot of P4 HW. I think that
> all family 15 uses the same PMU. Could someone confirm this?
A NC State University professor mentioned that the ommission of model 3
was a problem because his machine were model 3. I suggested the addition
of case for model 3 processors to get him going on that.
-Will
next prev parent reply other threads:[~2006-06-26 17:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 14:24 2.6.17.1 new perfmon code base, libpfm, pfmon available Stephane Eranian
2006-06-21 14:24 ` Stephane Eranian
2006-06-23 21:13 ` [perfmon] " William Cohen
2006-06-23 21:13 ` William Cohen
2006-06-23 21:23 ` [Perfctr-devel] " Stephane Eranian
2006-06-23 21:23 ` Stephane Eranian
2006-06-26 17:10 ` William Cohen [this message]
2006-06-26 17:10 ` William Cohen
2006-06-26 17:33 ` Chuck Ebbert
2006-06-26 17:33 ` Chuck Ebbert
2006-06-26 19:32 ` Grant Grundler
2006-06-26 19:32 ` Grant Grundler
2006-06-26 22:37 ` Stephane Eranian
2006-06-26 22:37 ` Stephane Eranian
2006-06-27 5:57 ` Chuck Ebbert
2006-06-27 5:57 ` Chuck Ebbert
2006-06-27 14:32 ` Stephane Eranian
2006-06-27 14:32 ` Stephane Eranian
2006-06-27 16:51 ` Grant Grundler
2006-06-27 16:51 ` Grant Grundler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44A0151D.5090400@redhat.com \
--to=wcohen@redhat.com \
--cc=eranian@hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oprofile-list@lists.sourceforge.net \
--cc=perfctr-devel@lists.sourceforge.net \
--cc=perfmon@napali.hpl.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.