From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Perfctr-Xen framework for permonace analysis Date: Fri, 13 May 2011 14:57:47 +0100 Message-ID: References: <682202.27833.qm@web113602.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <682202.27833.qm@web113602.mail.gq1.yahoo.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ruslan Nikolaev Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thu, May 12, 2011 at 9:35 PM, Ruslan Nikolaev wrote: > Well, at least it can peacefully coexist with oprofile. AFAIK, XenOProf h= as some limitations (system wide monitoring only), and works only with OPro= file. Many people would also prefer to use PAPI/HPCToolkit/PerfExplorer. HP= CToolkit itself is quite sophisticated framework with elaborated functional= ity. It is quite comparable to OProfile. PerfExplorer is also a very intere= sting project. PAPI is used by developers to do wide range of measurements = which are not necessarily possible with OProfile. The key feature of Perfct= r-Xen is that it allows to do all levels of performance monitoring, it does= not restrict to profiling. xenoprof enables the normal Linux oprofile, which can be used on processes, as well as on domains and on Xen itself. I don't remember if oprofile allows collection of performance counters on individual processes though; I suspect not. I'm a bit torn -- if people are used to using oprofile under Linux, it may be advantageous to keep that, rather than replacing it outright with a new tool. But as you said about the scheduler, Keir, oprofile gets little enough love as it is... -George > > This framework and xenoprof provide orthogonal solutions which both can b= e used in different circumstances. > > Thanks, > Ruslan Nikolaev > > --- On Fri, 5/13/11, Keir Fraser wrote: > >> From: Keir Fraser >> Subject: Re: [Xen-devel] Perfctr-Xen framework for permonace analysis >> To: "Ruslan Nikolaev" , xen-devel@lists.xensour= ce.com >> Date: Friday, May 13, 2011, 12:09 AM >> On 12/05/2011 20:36, "Ruslan >> Nikolaev" >> wrote: >> >> > Hi >> > >> > I want to make an announcement about new perfomance >> monitoring framework. >> > >> > Perfctr-Xen framework that enables per-thread >> performance analysis in Xen. >> > Current version is capable of properly virtualizing >> counters in both >> > paravirtualized and HVM modes. It is based on perfctr >> (which is a library and >> > kernel module for non-virtualized guests), ported to >> Xen, and extended to work >> > properly in virtualized environment. Both accumulative >> and interrupt modes >> > counting (profiling) are supported. >> > >> > The advantage of Perfctr-Xen is that it does not >> require specific HVM >> > extensions which are needed for vpmu driver, can work >> in paravirtualized mode, >> > and it also quite universal: works with many common >> tools such as PAPI, >> > HPCToolkit, TAU PerfExplorer. It supports proper >> per-domain and per-thread >> > virtualization. It is light-weight, supports wide >> range of CPUs, does not >> > require save-and-restore for accumulative mode of >> counting (it uses counter >> > offsetting), avoids expensive hypercalls and counter >> re-programming in certain >> > circumstances (when threads are counting the same type >> of events). In >> > addition, some techniques are employed to account for >> the overhead caused by >> > the framework itself. This makes measurements quite >> accurate. >> > >> > Perfctr-Xen consists of series of patches that need to >> be applied to Xen, >> > Linux, perfctr. There are available at: >> > http://people.cs.vt.edu/~rnikola/ >> > >> > The code is available under LGPL. It would be great to >> discuss if and how it >> > can be integrated into Xen. >> >> Could it reasonably replace the oprofile stuff we have >> already? I wouldn't >> want yet another perfctr subsystem/interface unless it >> supplants an existing >> one. We need a revolving door policy here I think. >> >> =A0-- Keir >> >> > The publication regarding Perfctr-Xen is at: >> > http://portal.acm.org/citation.cfm?id=3D1952687 >> > >> > Thanks, >> > Ruslan Nikolaev >> > >> > _______________________________________________ >> > 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 >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >