[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-ppc-devel
Subject:    Re: [XenPPC] Profiling in xen =?UTF-8?Q?=E2=80=93?= ppc considerations
From:       Hollis Blanchard <hollisb () us ! ibm ! com>
Date:       2007-03-20 15:49:20
Message-ID: 1174405760.24703.30.camel () basalt
[Download RAW message or body]

On Mon, 2007-03-19 at 15:48 +0100, Christian Ehrhardt wrote:
> Jimi Xenidis wrote:
> > ...
> > There really very little Linux work to do here.  We need:
> >  1. An hcall that turn the performance monitor on for the domain
> >  2. Save and restore the relevant registers for any domain that is has 
> > it turned on.
> >  3. Turn it off for domains that have it disabled.
> >
> > you can see the hcall being setup here:
> >   arch/powerpc/platforms/pseries/setup.c pSeries_setup_arch 322 
> > ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
> >
> > ...
> 
> I have evaluated all three items you listed above and I think to know 
> now what to do to implement them in detail. I will post a refined 
> version of your list after  I have clarified the last open thing. You 
> suggested to use the hcall to enable performance monitoring and I looked 
> at the definition. The hcall currently contains a lot of information 
> like perf granularity, function pointer, ...

There is no function pointer. There is "high"/"low" granularity. I
haven't really looked into this area so I'm not sure what those
correspond to, but at worst we could ignore them for now.

> Currently I expect to need only to set a interdomain valid flag telling 
> xen "there is some profiling in progress" and optional a per domain flag 
> "this one is currently profiling" via an hcall for the first step of the 
> implementation. Because the guest can write all performance special 
> purpose registers xen needs only this flag to know if it has to 
> store/recover the perfmon registers.
> We will need to restore MSR0/1,MSRA, PMC also for non-profiling guests 
> in context switch from a profiling one to non profiling guests, because 
> of that the easiest first implementation is something like the following 
> in context_switch().
> ...
> if (perf_mon_in_use) {
>    save/restore  MSR0/1,MSRA,PMC's
> }
> ...
> This will become more sophisticated in future but I currently expect 
> that we will not need the function pointer or profiling granularity 
> there for guest sampling. The only thing I currently expect for the 
> function pointer is to tell xen the place where to report hypervisor 
> samples in one of the next implementation steps.
> Should/Can I use this complex hcall to set that simple flag e.g. by 
> skipping all other attributes or do we need a new one?

I think you should use the current H_PERFMON hcall. It's really not
complex...

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[prev in list] [next in list] [prev in thread] [next in thread]