From: Maynard J. <may...@us...> - 2005-09-19 21:26:43
Attachments:
oprof-gps-patch
|
The Power 4 and PowerPC970 chips require the SAMPLE_ENABLE bit (MMCRA[63]) be set to '1' for the purpose of sampling. In the early days of PPC64 support for OProfile, the PPC64 driver was coded such that it always forced this bit to '1' for all PPC64 processors. However, we've gotten feedback from users telling us this usually not the appropriate behavior for Power5. Our response to this user feedback involves two actions: 1) Change the PPC64 kernel driver for OProfile (in mainline kernel development tree) so it sets the SAMPLE_ENABLE bit based on values passed from userspace. 2) Change the PPC64 event information files in OProfile userspace so the bit is set as appropriate for the type of processor. Action #1 will, of course, be handled via the LKML. The attached patch addresses action #2. Additionally, this patch adds a new event to the Power5 event info files, based on user request. This patch will have no effect on Power4 and PowerPC970 users -- it merely changes which side of the user/kernel interface is forcing the SAMPLE_ENABLE bit to '1'. Power5 users will not see any difference until they are able to run OProfile on a kernel version that has the patch described above in action #1. At that time, they will be able to choose between the two different modes of sampling available on the Power5 -- random and continuous. Thanks. Maynard |
From: Anton B. <an...@sa...> - 2005-09-27 07:40:57
|
Hi, On Mon, Sep 19, 2005 at 04:26:24PM -0500, Maynard Johnson wrote: > The Power 4 and PowerPC970 chips require the SAMPLE_ENABLE bit > (MMCRA[63]) be set to '1' for the purpose of sampling. In the early > days of PPC64 support for OProfile, the PPC64 driver was coded such that > it always forced this bit to '1' for all PPC64 processors. However, > we've gotten feedback from users telling us this usually not the > appropriate behavior for Power5. Our response to this user feedback > involves two actions: > 1) Change the PPC64 kernel driver for OProfile (in mainline kernel > development tree) so it sets the SAMPLE_ENABLE bit based on values > passed from userspace. John, any chance we can get this patch into oprofile CVS? I was hoping to get the kernel patch into mainline for 2.6.15 and at that stage users will need to update to the new oprofile userspace. > 2) Change the PPC64 event information files in OProfile userspace so > the bit is set as appropriate for the type of processor. > > Action #1 will, of course, be handled via the LKML. The attached patch > addresses action #2. Additionally, this patch adds a new event to the > Power5 event info files, based on user request. > > This patch will have no effect on Power4 and PowerPC970 users -- it > merely changes which side of the user/kernel interface is forcing the > SAMPLE_ENABLE bit to '1'. Power5 users will not see any difference > until they are able to run OProfile on a kernel version that has the > patch described above in action #1. At that time, they will be able to > choose between the two different modes of sampling available on the > Power5 -- random and continuous. |
From: Philippe E. <ph...@wa...> - 2005-09-27 13:19:45
|
On Tue, 27 Sep 2005 at 17:40 +0000, Anton Blanchard wrote: > > Hi, > > On Mon, Sep 19, 2005 at 04:26:24PM -0500, Maynard Johnson wrote: > > The Power 4 and PowerPC970 chips require the SAMPLE_ENABLE bit > > (MMCRA[63]) be set to '1' for the purpose of sampling. In the early > > days of PPC64 support for OProfile, the PPC64 driver was coded such that > > it always forced this bit to '1' for all PPC64 processors. However, > > we've gotten feedback from users telling us this usually not the > > appropriate behavior for Power5. Our response to this user feedback > > involves two actions: > > 1) Change the PPC64 kernel driver for OProfile (in mainline kernel > > development tree) so it sets the SAMPLE_ENABLE bit based on values > > passed from userspace. > > John, any chance we can get this patch into oprofile CVS? I was hoping > to get the kernel patch into mainline for 2.6.15 and at that stage users > will need to update to the new oprofile userspace. Before applying it a question. Does this patch break user that will use a new kernel and old oprofile tools or do you plan to workaround it in the kernel by setting the bits for the right processor. In this case this patch is not necessary except as cleanup to clarify the real setting of this bit. I mean adding something like this pseudo-code in the kernel to ensure using a new kernel with old oprofile tools will work: /* provide compatility with older oprofile tools */ if (cpu_type == power4 || cpu_type == 970) mccra |= 1; -- Phil |
From: Maynard J. <may...@us...> - 2005-09-28 23:12:22
|
Philippe Elie wrote: > On Tue, 27 Sep 2005 at 17:40 +0000, Anton Blanchard wrote: > > >>Hi, >> >>On Mon, Sep 19, 2005 at 04:26:24PM -0500, Maynard Johnson wrote: >> >>>The Power 4 and PowerPC970 chips require the SAMPLE_ENABLE bit >>>(MMCRA[63]) be set to '1' for the purpose of sampling. In the early >>>days of PPC64 support for OProfile, the PPC64 driver was coded such that >>>it always forced this bit to '1' for all PPC64 processors. However, >>>we've gotten feedback from users telling us this usually not the >>>appropriate behavior for Power5. Our response to this user feedback >>>involves two actions: >>> 1) Change the PPC64 kernel driver for OProfile (in mainline kernel >>>development tree) so it sets the SAMPLE_ENABLE bit based on values >>>passed from userspace. >> >>John, any chance we can get this patch into oprofile CVS? I was hoping >>to get the kernel patch into mainline for 2.6.15 and at that stage users >>will need to update to the new oprofile userspace. > > > Before applying it a question. Does this patch break user that will > use a new kernel and old oprofile tools or do you plan to workaround > it in the kernel by setting the bits for the right processor. In this > case this patch is not necessary except as cleanup to clarify the real > setting of this bit. I mean adding something like this pseudo-code > in the kernel to ensure using a new kernel with old oprofile tools will > work: > > /* provide compatility with older oprofile tools */ > if (cpu_type == power4 || cpu_type == 970) > mccra |= 1; From my perspective, I think this is a good suggestion. Anton, what's your opinion on having something like this in the kernel driver? If we went this route, IMHO, I still think it would be good to apply the user level patch as is. -Maynard > > -- Phil > > |
From: Anton B. <an...@sa...> - 2005-10-07 19:02:37
|
Hi, > From my perspective, I think this is a good suggestion. Anton, what's > your opinion on having something like this in the kernel driver? If we > went this route, IMHO, I still think it would be good to apply the user > level patch as is. The hope was to remove that bit of logic since it didnt belong in the kernel. I guess we could add something to catch 970 and power4. Having said that, I dont think this discussion should postpone applying your userspace oprofile patch. It sets things up correctly for POWER5 which we will need to exploit the kernel changes. Anton |
From: Maynard J. <may...@us...> - 2005-10-13 19:42:27
|
Hi, Philippe, Anton indicates below he's open to adding something in the kernel driver to handle the 970 and power4 cases if older oprofile is used on top of a newer kernel. So, can we get the user space patch applied now? Thanks. -Maynard Anton Blanchard wrote: > Hi, > > >>From my perspective, I think this is a good suggestion. Anton, what's >>your opinion on having something like this in the kernel driver? If we >>went this route, IMHO, I still think it would be good to apply the user >>level patch as is. > > > The hope was to remove that bit of logic since it didnt belong in the > kernel. I guess we could add something to catch 970 and power4. > > Having said that, I dont think this discussion should postpone applying > your userspace oprofile patch. It sets things up correctly for POWER5 > which we will need to exploit the kernel changes. > > Anton > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: John L. <le...@mo...> - 2005-10-13 23:36:03
|
On Thu, Oct 13, 2005 at 02:41:57PM -0500, Maynard Johnson wrote: > Anton indicates below he's open to adding something in the kernel driver > to handle the 970 and power4 cases if older oprofile is used on top of a > newer kernel. So, can we get the user space patch applied now? I'm fine with it, it's just a matter of Phil finding a spare moment to do so (which I do not possess...) john |
From: Maynard J. <may...@us...> - 2005-10-18 15:50:07
Attachments:
oprof-gps-patch
|
John Levon wrote: > On Thu, Oct 13, 2005 at 02:41:57PM -0500, Maynard Johnson wrote: > > >>Hi, Philippe, >>Anton indicates below he's open to adding something in the kernel driver >>to handle the 970 and power4 cases if older oprofile is used on top of a >>newer kernel. So, can we get the user space patch applied now? > > > Please resend the patch + change log. > > john > OK, I "freshened" the patch against today's CVS, fixing up the ChangeLog entry. Below is the original text of the note I sent when I first posted the patch. ================================================================ The Power 4 and PowerPC970 chips require the SAMPLE_ENABLE bit (MMCRA[63]) be set to '1' for the purpose of sampling. In the early days of PPC64 support for OProfile, the PPC64 driver was coded such that it always forced this bit to '1' for all PPC64 processors. However, we've gotten feedback from users telling us this usually not the appropriate behavior for Power5. Our response to this user feedback involves two actions: 1) Change the PPC64 kernel driver for OProfile (in mainline kernel development tree) so it sets the SAMPLE_ENABLE bit based on values passed from userspace. 2) Change the PPC64 event information files in OProfile userspace so the bit is set as appropriate for the type of processor. Action #1 will, of course, be handled via the LKML. The attached patch addresses action #2. Additionally, this patch adds a new event to the Power5 event info files, based on user request. This patch will have no effect on Power4 and PowerPC970 users -- it merely changes which side of the user/kernel interface is forcing the SAMPLE_ENABLE bit to '1'. Power5 users will not see any difference until they are able to run OProfile on a kernel version that has the patch described above in action #1. At that time, they will be able to choose between the two different modes of sampling available on the Power5 -- random and continuous. Thanks. Maynard |
From: John L. <le...@mo...> - 2005-10-18 22:47:47
|
On Tue, Oct 18, 2005 at 10:49:43AM -0500, Maynard Johnson wrote: > OK, I "freshened" the patch against today's CVS, fixing up the ChangeLog Applied. thanks john |