OK, I''ve been fritzing around with something I noticed last night, thinking that I understood what was going on, but now it''s getting confusing again. A system that has been running for a couple of months had a hole in the probe ID list near the end in the middle of the fbt probes. And then a couple of syscall probes were stuck in the hole. It looked like this: ... 40311 fbt cpuid cpuid_detach entry 40312 fbt cpuid cpuid_detach return 40313 fbt cpuid _info entry 40314 fbt cpuid _info return 40315 syscall cpc entry 40316 syscall cpc return 68862 fbt ksyms ksyms_open entry 68863 fbt ksyms ksyms_open return 68864 fbt ksyms ksyms_close entry 68865 fbt ksyms ksyms_close return 68866 fbt ksyms ksyms_read entry 68867 fbt ksyms ksyms_read return ... I kind of assumed that this happens when modules are loaded and unloaded. I was attempted to prove this by modunloading something, but I couldn''t find any that weren''t busy, so I just did a "modunload -i 0" and unloaded all of the auto loaded modules that I could.. When the modunload completed, a fresh "dtrace -l", too my surprise, instead of having holes, was now completely contiguous. In addition, the list has been shuffled (i.e. syscall::acctctl has been removed and everything below shifted up to fill the gap). Also, the "cpc" syscall above now appears at probe IDs 308 and 309. So why would modunload sometimes leave gaps and sometimes cause a re-shuffle, and if "cpc" was part of the original syscall list (not auto loaded), why was it moved to 40315 at some point? Thanks, Chip
On Fri, Jul 07, 2006 at 03:29:25PM -0500, Chip Bennett wrote:> OK, I''ve been fritzing around with something I noticed last night, > thinking that I understood what was going on, but now it''s getting > confusing again. > > A system that has been running for a couple of months had a hole in the > probe ID list near the end in the middle of the fbt probes. And then a > couple of syscall probes were stuck in the hole. It looked like this: > > ... > 40311 fbt cpuid cpuid_detach entry > 40312 fbt cpuid cpuid_detach return > 40313 fbt cpuid _info entry > 40314 fbt cpuid _info return > 40315 syscall cpc entry > 40316 syscall cpc return > 68862 fbt ksyms ksyms_open entry > 68863 fbt ksyms ksyms_open return > 68864 fbt ksyms ksyms_close entry > 68865 fbt ksyms ksyms_close return > 68866 fbt ksyms ksyms_read entry > 68867 fbt ksyms ksyms_read return > ... > > I kind of assumed that this happens when modules are loaded and > unloaded. I was attempted to prove this by modunloading something, but > I couldn''t find any that weren''t busy, so I just did a "modunload -i 0" > and unloaded all of the auto loaded modules that I could.. > > When the modunload completed, a fresh "dtrace -l", too my surprise, > instead of having holes, was now completely contiguous. In addition, > the list has been shuffled (i.e. syscall::acctctl has been removed and > everything below shifted up to fill the gap). Also, the "cpc" syscall > above now appears at probe IDs 308 and 309.Presumably, the provider modules were unloaded, and unregistered all of their probes. When you did the dtrace -l, they were re-loaded, and created their probes in sequence, removing any holes. CPC is a loadable system call; until it is loaded, the system call won''t appear. Cheers, - jonathan> So why would modunload sometimes leave gaps and sometimes cause a > re-shuffle, and if "cpc" was part of the original syscall list (not auto > loaded), why was it moved to 40315 at some point? > > Thanks, > Chip > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Jonathan Adams, Solaris Kernel Development
Yep. Here''s the diff between modinfo after the unload and then after the fresh "dtrace -l": 130a131,132 > 141 13e74c8 50f8 223 1 fasttrap (Fasttrap Tracing) > 142 13d7900 2730 219 1 fbt (Function Boundary Tracing) 132a135,138 > 145 7ba459a0 a60 89 1 lockstat (Lock Statistics 1.9) > 146 7bf4c408 c90 220 1 profile (Profile Interrupt Tracing) > 147 7baf4a88 2010 222 1 sdt (Statically Defined Tracing) > 148 7bfb8888 7b0 221 1 systrace (System Call Tracing) Makes sense. Thanks, Chip Jonathan Adams wrote:>On Fri, Jul 07, 2006 at 03:29:25PM -0500, Chip Bennett wrote: > > >>OK, I''ve been fritzing around with something I noticed last night, >>thinking that I understood what was going on, but now it''s getting >>confusing again. >> >>A system that has been running for a couple of months had a hole in the >>probe ID list near the end in the middle of the fbt probes. And then a >>couple of syscall probes were stuck in the hole. It looked like this: >> >>... >>40311 fbt cpuid cpuid_detach entry >>40312 fbt cpuid cpuid_detach return >>40313 fbt cpuid _info entry >>40314 fbt cpuid _info return >>40315 syscall cpc entry >>40316 syscall cpc return >>68862 fbt ksyms ksyms_open entry >>68863 fbt ksyms ksyms_open return >>68864 fbt ksyms ksyms_close entry >>68865 fbt ksyms ksyms_close return >>68866 fbt ksyms ksyms_read entry >>68867 fbt ksyms ksyms_read return >>... >> >>I kind of assumed that this happens when modules are loaded and >>unloaded. I was attempted to prove this by modunloading something, but >>I couldn''t find any that weren''t busy, so I just did a "modunload -i 0" >>and unloaded all of the auto loaded modules that I could.. >> >>When the modunload completed, a fresh "dtrace -l", too my surprise, >>instead of having holes, was now completely contiguous. In addition, >>the list has been shuffled (i.e. syscall::acctctl has been removed and >>everything below shifted up to fill the gap). Also, the "cpc" syscall >>above now appears at probe IDs 308 and 309. >> >> > >Presumably, the provider modules were unloaded, and unregistered all of their >probes. When you did the dtrace -l, they were re-loaded, and created their >probes in sequence, removing any holes. > >CPC is a loadable system call; until it is loaded, the system call won''t >appear. > >Cheers, >- jonathan > > > >>So why would modunload sometimes leave gaps and sometimes cause a >>re-shuffle, and if "cpc" was part of the original syscall list (not auto >>loaded), why was it moved to 40315 at some point? >> >>Thanks, >>Chip >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> >> > > >