On 12/10/08 21:39, Li, Aubrey wrote: [snip] >> (a) tie fbt::xc_common firings to fbt::send_dirint on x86 and >> > fbt::init_mondo calls to fbt::shipit on sun4v. >> > >> > or >> > >> > (b) tie fbt::xc_common and fbt::init_mondo to sysinfo:::xcalls >> > >> > On both cases we'll need to catch free/untied firings of >> > sysinfo:::xcalls for specific situations. >> > >> > The patch I sent for the --cpu option needs fbt::send_dirint (and >> > fbt::shipt) to catch incoming xcalls. So I'd suggest using (a) above. >> > >> > What do you think ? >> > > > a) sounds good. But can we still get the xcall function name if we use > send_dirint? > I have a quick try and the xcalls number still quite different from the > current implementation. > Can you confirm it on a 8-core platform? > > As for SPARC, I didn't have a platform to try, you have to be on your own, > :) > > Thanks, > -Aubrey >
Here's an exported changeset for these changes. A few changes on this one.. Because xc_common and init_mondo are platform specific DTrace probes, I had to create a new file (dtp_events.c) per platform folder. This new file contains the scripts for the event reports. For clarity sake, I moved the common source files to a new folder 'common' and updated the Makefiles accordingly. fbt::send_dirint (and its SPARC counterpart) fire for events which we're not necessarily interested, cyclics for instance. So I need to look into that and see what can be done for the --cpu option. This changeset is basically looking at sysinfo:::xcalls, but noting the function whenever possible through xc_common. I don't see another way of catching the routine responsible for the xcall at this time. I tested this patch on an idle two quad core Xeon and the amount of xcalls matched the current ptop version. Let me know what you think. Thanks, Rafael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 7770.exp URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20081215/e77054c5/attachment.ksh>
