[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XenPPC] Profiling in xen â ppc considerations
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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |