Santos, Jose Renato G
2009-Jun-23 18:13 UTC
[Xen-devel] [PATCH] Oprofile patch for 2.6.27 tree. Fix collision between Xen and Cell processor escape codes
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jun-24 08:15 UTC
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>>> "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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Santos, Jose Renato G
2009-Jun-25 02:04 UTC
RE: [Xen-devel] [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes
> -----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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Smith
2009-Jun-25 09:50 UTC
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.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 > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2009-Jun-26 08:25 UTC
Re: [Xen-devel] [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Smith
2009-Jun-30 10:48 UTC
Re: [Xen-devel] [PATCH] Oprofile patch for 2.6.27 tree. Fix collisionbetween Xen and Cell processor escape codes
> >> 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.I don''t see it at git://xenbits.xensource.com/xenclient/linux-2.6.27-pq.git . Is there some other tree I should be pulling from? Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel