[PATCH] Oprofile patch for 2.6.27 tree. Fix collision between Xen and Cell processor escape codes

[PATCH] Oprofile patch for 2.6.27 tree. Fix collision between Xen and Cell processor escape codes

[Santos, Jose Renato G]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

 
Steven

This is a fix to enable Oprofile to work on the netchannel2 2.6.27 tree.

This is to address a collision for escape codes used to represent domain switches in Xen and CPU switches in cell processors which were developed in parallel and used the same code.

There was a discussion on the Oprofile mailing list a while ago and it was decided that we would use different Oprofile codes for x86 and ia64 archs (which are the only ones that support Oprofile in Xen) in order to preserve backward compatibility for users.

The Oprofile user level tools expect different escape codes depending on the architecture. We need to make sure the kernel generates compatible escape codes.

I think this should be also pushed to the 2.6.27 XenClient tree.

Thanks

Renato

[-- Attachment #2: fix_domain_switch_code.diff --]
[-- Type: application/octet-stream, Size: 1072 bytes --]

commit 28724aa980156dcd3cc7f15207267341e092c6c3
Author: Jose Renato Santos <jsantos@hpl.hp.com>
Date:   Mon Jun 22 11:56:37 2009 -0700

    Fix OProfile escape code collision between Xenoprof's
    DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
    SPU_PROFILING_CODE(in use with Power)
    
    Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>

diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
index bb8a349..44a2138 100644
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -37,9 +37,18 @@
 #define TRACE_BEGIN_CODE		8
 #define TRACE_END_CODE			9
 #define XEN_ENTER_SWITCH_CODE		10
+/*
+ * Ugly work-around for the unfortunate collision between Xenoprof's
+ * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
+ * (in use with Power):
+ */
+#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64) || defined(CONFIG_IA64) 
+#define DOMAIN_SWITCH_CODE		11
+#else
 #define SPU_PROFILING_CODE		11
 #define SPU_CTX_SWITCH_CODE		12
 #define DOMAIN_SWITCH_CODE		13
+#endif
 
 struct super_block;
 struct dentry;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes

[Jan Beulich]

I'm a little confused by this: Upstream oprofile 0.9.4 has the same workaround implemented on the user mode side of things, so adjusting this in the kernel now would make the kernel incompatible with that and future versions. Jan

>>> "Santos, Jose Renato G" <joserenato.santos@hp.com> 23.06.09 20:13 >>>

Steven

This is a fix to enable Oprofile to work on the netchannel2 2.6.27 tree.

This is to address a collision for escape codes used to represent domain switches in Xen and CPU switches in cell processors which were developed in parallel and used the same code.

There was a discussion on the Oprofile mailing list a while ago and it was decided that we would use different Oprofile codes for x86 and ia64 archs (which are the only ones that support Oprofile in Xen) in order to preserve backward compatibility for users.

The Oprofile user level tools expect different escape codes depending on the architecture. We need to make sure the kernel generates compatible escape codes.

I think this should be also pushed to the 2.6.27 XenClient tree.

Thanks

Renato

RE: [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes

[Santos, Jose Renato G]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

 

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@novell.com] 
> Sent: Wednesday, June 24, 2009 1:15 AM
> To: Steven Smith; Santos, Jose Renato G
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Oprofile patch for 2.6.27 
> tree. Fix collisionbetween Xen and Cell processor escape codes
> 
> I'm a little confused by this: Upstream oprofile 0.9.4 has 
> the same workaround implemented on the user mode side of 
> things, so adjusting this in the kernel now would make the 
> kernel incompatible with that and future versions. Jan
> 

  The fact that oprofile user level code has the same workaround
  is exactly the reason for this patch.
  We need the same code values in the kernel and in the user level tools.
  Right now the kernel generates code 13 for DOMAIN_SWITCH_CODE
  in x86 and Oprofile daemon complains that there is no such code.
  (it expects code 11 for that).
  
  However, your question made me look at Oprofile 0.9.4 and I noticed
  this workaround changed slightly from 0.9.3 to 0.9.4.
  The new code checks for powerpc while 0.9.3 checked for
  x96 and ia64. So we need a slightly different patch.

  Please use the new attached patch instead of the original one. 

  Thanks 

Renato

===============================================

    Fix OProfile escape code collision between Xenoprof's
    DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
    SPU_PROFILING_CODE(in use with Power).
    
    Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>

diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
index bb8a349..8863734 100644
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -37,9 +37,18 @@
 #define TRACE_BEGIN_CODE		8
 #define TRACE_END_CODE			9
 #define XEN_ENTER_SWITCH_CODE		10
+/*
+ * Ugly work-around for the unfortunate collision between Xenoprof's
+ * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
+ * (in use with Power):
+ */
+#ifdef CONFIG_PPC
 #define SPU_PROFILING_CODE		11
 #define SPU_CTX_SWITCH_CODE		12
 #define DOMAIN_SWITCH_CODE		13
+#else
+#define DOMAIN_SWITCH_CODE		11
+#endif
 
 struct super_block;
 struct dentry;


> >>> "Santos, Jose Renato G" <joserenato.santos@hp.com> 23.06.09 20:13 
> >>> >>>
> 
> Steven
> 
> This is a fix to enable Oprofile to work on the netchannel2 
> 2.6.27 tree.
> 
> This is to address a collision for escape codes used to 
> represent domain switches in Xen and CPU switches in cell 
> processors which were developed in parallel and used the same code.
> 
> There was a discussion on the Oprofile mailing list a while 
> ago and it was decided that we would use different Oprofile 
> codes for x86 and ia64 archs (which are the only ones that 
> support Oprofile in Xen) in order to preserve backward 
> compatibility for users.
> 
> The Oprofile user level tools expect different escape codes 
> depending on the architecture. We need to make sure the 
> kernel generates compatible escape codes.
> 
> I think this should be also pushed to the 2.6.27 XenClient tree.
> 
> Thanks
> 
> Renato
> 
> 

[-- Attachment #2: fix_domain_switch_code.diff --]
[-- Type: application/octet-stream, Size: 1013 bytes --]

commit 5f83a329fe07bdfcb6ced6de35f6fc68b22b99e0
Author: Jose Renato Santos <jsantos@hpl.hp.com>
Date:   Wed Jun 24 18:18:41 2009 -0700

    Fix OProfile escape code collision between Xenoprof's
    DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
    SPU_PROFILING_CODE(in use with Power).
    
    Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>

diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
index bb8a349..8863734 100644
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -37,9 +37,18 @@
 #define TRACE_BEGIN_CODE		8
 #define TRACE_END_CODE			9
 #define XEN_ENTER_SWITCH_CODE		10
+/*
+ * Ugly work-around for the unfortunate collision between Xenoprof's
+ * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
+ * (in use with Power):
+ */
+#ifdef CONFIG_PPC
 #define SPU_PROFILING_CODE		11
 #define SPU_CTX_SWITCH_CODE		12
 #define DOMAIN_SWITCH_CODE		13
+#else
+#define DOMAIN_SWITCH_CODE		11
+#endif
 
 struct super_block;
 struct dentry;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes

[Steven Smith]

[-- Attachment #1.1.1: Type: text/plain, Size: 3035 bytes --]

> > I'm a little confused by this: Upstream oprofile 0.9.4 has 
> > the same workaround implemented on the user mode side of 
> > things, so adjusting this in the kernel now would make the 
> > kernel incompatible with that and future versions. Jan
>   The fact that oprofile user level code has the same workaround
>   is exactly the reason for this patch.
>   We need the same code values in the kernel and in the user level tools.
>   Right now the kernel generates code 13 for DOMAIN_SWITCH_CODE
>   in x86 and Oprofile daemon complains that there is no such code.
>   (it expects code 11 for that).
>   
>   However, your question made me look at Oprofile 0.9.4 and I noticed
>   this workaround changed slightly from 0.9.3 to 0.9.4.
>   The new code checks for powerpc while 0.9.3 checked for
>   x96 and ia64. So we need a slightly different patch.
> 
>   Please use the new attached patch instead of the original one. 
Ian: Can you apply this to the 2.6.27 tree, please?  I'll pull it
through to NC2 from there.

Steven.

>     Fix OProfile escape code collision between Xenoprof's
>     DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
>     SPU_PROFILING_CODE(in use with Power).
>     
>     Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>
> 
> diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
> index bb8a349..8863734 100644
> --- a/include/linux/oprofile.h
> +++ b/include/linux/oprofile.h
> @@ -37,9 +37,18 @@
>  #define TRACE_BEGIN_CODE		8
>  #define TRACE_END_CODE			9
>  #define XEN_ENTER_SWITCH_CODE		10
> +/*
> + * Ugly work-around for the unfortunate collision between Xenoprof's
> + * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
> + * (in use with Power):
> + */
> +#ifdef CONFIG_PPC
>  #define SPU_PROFILING_CODE		11
>  #define SPU_CTX_SWITCH_CODE		12
>  #define DOMAIN_SWITCH_CODE		13
> +#else
> +#define DOMAIN_SWITCH_CODE		11
> +#endif
>  
>  struct super_block;
>  struct dentry;
> 
> 




> > >>> "Santos, Jose Renato G" <joserenato.santos@hp.com> 23.06.09 20:13 
> > >>> >>>
> > 
> > Steven
> > 
> > This is a fix to enable Oprofile to work on the netchannel2 
> > 2.6.27 tree.
> > 
> > This is to address a collision for escape codes used to 
> > represent domain switches in Xen and CPU switches in cell 
> > processors which were developed in parallel and used the same code.
> > 
> > There was a discussion on the Oprofile mailing list a while 
> > ago and it was decided that we would use different Oprofile 
> > codes for x86 and ia64 archs (which are the only ones that 
> > support Oprofile in Xen) in order to preserve backward 
> > compatibility for users.
> > 
> > The Oprofile user level tools expect different escape codes 
> > depending on the architecture. We need to make sure the 
> > kernel generates compatible escape codes.
> > 
> > I think this should be also pushed to the 2.6.27 XenClient tree.
> > 
> > Thanks
> > 
> > Renato
> > 
> > 


[-- Attachment #1.1.2: fix_domain_switch_code.diff --]
[-- Type: text/x-diff, Size: 1046 bytes --]

commit 5f83a329fe07bdfcb6ced6de35f6fc68b22b99e0
Author: Jose Renato Santos <jsantos@hpl.hp.com>
Date:   Wed Jun 24 18:18:41 2009 -0700

    Fix OProfile escape code collision between Xenoprof's
    DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
    SPU_PROFILING_CODE(in use with Power).
    
    Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>

diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
index bb8a349..8863734 100644
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -37,9 +37,18 @@
 #define TRACE_BEGIN_CODE		8
 #define TRACE_END_CODE			9
 #define XEN_ENTER_SWITCH_CODE		10
+/*
+ * Ugly work-around for the unfortunate collision between Xenoprof's
+ * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
+ * (in use with Power):
+ */
+#ifdef CONFIG_PPC
 #define SPU_PROFILING_CODE		11
 #define SPU_CTX_SWITCH_CODE		12
 #define DOMAIN_SWITCH_CODE		13
+#else
+#define DOMAIN_SWITCH_CODE		11
+#endif
 
 struct super_block;
 struct dentry;

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes

[Jean Guyader]

2009/6/25 Steven Smith <steven.smith@citrix.com>:
>> > I'm a little confused by this: Upstream oprofile 0.9.4 has
>> > the same workaround implemented on the user mode side of
>> > things, so adjusting this in the kernel now would make the
>> > kernel incompatible with that and future versions. Jan
>>   The fact that oprofile user level code has the same workaround
>>   is exactly the reason for this patch.
>>   We need the same code values in the kernel and in the user level tools.
>>   Right now the kernel generates code 13 for DOMAIN_SWITCH_CODE
>>   in x86 and Oprofile daemon complains that there is no such code.
>>   (it expects code 11 for that).
>>
>>   However, your question made me look at Oprofile 0.9.4 and I noticed
>>   this workaround changed slightly from 0.9.3 to 0.9.4.
>>   The new code checks for powerpc while 0.9.3 checked for
>>   x96 and ia64. So we need a slightly different patch.
>>
>>   Please use the new attached patch instead of the original one.
> Ian: Can you apply this to the 2.6.27 tree, please?  I'll pull it
> through to NC2 from there.
>

I've applied this patch on the XCI 2.6.27 tree, it should be available soon.

Thanks,
Jean

>
>>     Fix OProfile escape code collision between Xenoprof's
>>     DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's
>>     SPU_PROFILING_CODE(in use with Power).
>>
>>     Signed-off-by: Jose Renato Santos <jsantos@hpl.hp.com>
>>
>> diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
>> index bb8a349..8863734 100644
>> --- a/include/linux/oprofile.h
>> +++ b/include/linux/oprofile.h
>> @@ -37,9 +37,18 @@
>>  #define TRACE_BEGIN_CODE             8
>>  #define TRACE_END_CODE                       9
>>  #define XEN_ENTER_SWITCH_CODE                10
>> +/*
>> + * Ugly work-around for the unfortunate collision between Xenoprof's
>> + * DOMAIN_SWITCH_CODE (in use on x86 and ia64) and Cell's SPU_PROFILING_CODE
>> + * (in use with Power):
>> + */
>> +#ifdef CONFIG_PPC
>>  #define SPU_PROFILING_CODE           11
>>  #define SPU_CTX_SWITCH_CODE          12
>>  #define DOMAIN_SWITCH_CODE           13
>> +#else
>> +#define DOMAIN_SWITCH_CODE           11
>> +#endif
>>
>>  struct super_block;
>>  struct dentry;
>>
>>
>
>
>
>
>> > >>> "Santos, Jose Renato G" <joserenato.santos@hp.com> 23.06.09 20:13
>> > >>> >>>
>> >
>> > Steven
>> >
>> > This is a fix to enable Oprofile to work on the netchannel2
>> > 2.6.27 tree.
>> >
>> > This is to address a collision for escape codes used to
>> > represent domain switches in Xen and CPU switches in cell
>> > processors which were developed in parallel and used the same code.
>> >
>> > There was a discussion on the Oprofile mailing list a while
>> > ago and it was decided that we would use different Oprofile
>> > codes for x86 and ia64 archs (which are the only ones that
>> > support Oprofile in Xen) in order to preserve backward
>> > compatibility for users.
>> >
>> > The Oprofile user level tools expect different escape codes
>> > depending on the architecture. We need to make sure the
>> > kernel generates compatible escape codes.
>> >
>> > I think this should be also pushed to the 2.6.27 XenClient tree.
>> >
>> > Thanks
>> >
>> > Renato
>> >
>> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFKQ0h/vAgSWYI3DVMRAvrQAKCfV2YQ85vQYGIUGWPzQHYuIBC6+QCgsgWA
> qxfSjs0f9H5JTvl+gU1ibHo=
> =rRNP
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

Perfcrt enabled kernel

[Ata Bohra]

[-- Attachment #1.1: Type: text/plain, Size: 1222 bytes --]


Dear All, 

 

I am trying to use perfctr driver along with centos 2.6.18-128.2.1.el5xen kernel. I tried following steps:

 

1. Installed the kernel source: src rpm (2.6.18-128.2.1.el5.src.rpm)

2. Patched the extracted kernel with perfcrt-2.6.38 available patch i.e. 2.6.18-128.el5-redhat.

3. Enabled the perfctr driver, global and virtual component

4. Atlast I tried to build, but the compile process gives an error while compiling kernel/sched.c. I tried to dig in to the code, but error says "perfcrt not found as a member in struct thread_struct", but the processor.h thread_struct has a member "perfctr". 

 

As the patch was available for 2.6.18-128.el5, I also tried to patch 2.6.18-128.el5xen which is installed by default unless you perform a "yum update", but still the same issue. 

 

Please suggest if someone is been successful in installing the perfctr driver.

 

Thanks in advance!

 

Regards,

Ata E Husain

University at Buffalo

_________________________________________________________________
MSN Quiz The clash is on to find the best brains. Test your skills with avid quizzers on MSN quiz.
http://specials.msn.co.in/WLSocialNetworkConnector/Chrome.aspx

[-- Attachment #1.2: Type: text/html, Size: 1438 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen diskI/O request handling!

[Ata E Husain]

Dear All, 

I am interested in developing better understanding in terms of handling of
disk request in dom0 from all domUs running in the system using blktap
architecture. The intension of developing this information is compute a
profile of disk access request (read + write) from all domUs at any instant
of time. 

If someone is conversant with this information, it would be a great help if
you can share which part of the xen tree should I be looking to get precise
information. I am done using 'iostat' to get the similar information but it
would be more useful if I can compute the information without need of
invoking any other executable etc. 

Thanks!
Ata