Messages in this thread | | | Date | Tue, 22 Jul 2008 07:51:01 -0400 | From | "Frank Ch. Eigler" <> | Subject | Re: [RFC] fix kallsyms to allow discrimination of local symbols |
| |
Hi -
On Mon, Jul 21, 2008 at 10:53:08PM -0500, James Bottomley wrote: > [...] > > - You disprefer systemtap's use of an established, non-deprecated API > > for placing kernel probes. [...] > > You mean embedding half a megabyte of symbols simply so you can avoid > the inconvenience of using a kernel API? yes, I think it's ... > suboptimal.
It has been explained already that the symbol table you saw in stap-symbols.h has nothing to do with the kprobe addressing issue.
http://www.gossamer-threads.com/lists/linux/kernel/947365#957365
> > - You argue that symbols+offset kprobing is better. We can see that, > > in some sense, but ... > > > > - I explain that we are used to final address calculating, as we'll > > have to do that regardless for user-space probes. Plus we need to > > work with kernels that predate the symbol+offset kprobe api > > extension. So this change would not simplify systemtap in any way. > > You do not respond. > > There is no current userspace infrastructure, since utrace still isn't > in the kernel, so you're predicating this argument on an event which > hasn't happened.
We exercise professional foresight. And the backward compatibility issue remains even without that.
> Even assuming utrace is accepted, embedding the symbol table of > every user space process in the probes is still daft. [....]
It would take space, no question, though we're not talking about "every" process, just designated ones.
> For instance, the obvious way to me of doing this would be to map > the user space stack into the systemtap runtime and unwind it from > there instead of vectoring it into the kernel.
Please elaborate. What does mapping a stack into the runtime mean? Do you mean to suggest having the userspace program unwind itself? Or relying on the userspace programs' possibly-paged-out unwind data? That would be intrusive.
> > - I offer _stext+offset (for the kernel) and (.text*)+offset (for > > modules) kprobes: basically to use the "better" symbol+offset > > kprobes api, but use the same single reference addresses we already > > do, and leaving just the final addition to the kernel. You do not > > respond materially. > > I thought this and subsequent emails addressed the points pretty well: > > http://marc.info/?l=linux-kernel&m=121632572409118
No, they didn't. Every time I explained about how it does work, you just claimed "not", without even a single worked-out substantiating example.
> [...] > > - storage of all that new file name data in permanent unswappable > > kernel data (>>100kB, if done simply prefixing local symbol names > > file file names). > > I'd check my facts before making assertions. The kernel symbol table is > stored in a compressed form that actually eliminates most of these > repetitions.
A careful reader will notice the "if" in my sentence. Anyway, that or a superior compression scheme could apply to systemtap's various tables too.
> > - possible further complications related to filename string matching > > Any substantiation of that?
We have had reported problems with differences between kernels hand-built with long absolute source path names versus the smallest "kernel/foo.c" names. If such canonicalization takes place but inconsistently by the different tools, we will have a problem.
> [...] > > In total, this path would end up with both systemtap and the kernel > > more complex, larger and a bit slower too. > > Really? I count the reduction of the probe modules from 500kb to 50kb a > worthwhile saving.
The red clupea harengus again.
> I don't even see where anything became larger.
Even with ksymtab compression, there is still new data to be stored in the kernel, and it is extra for each systemtap probe datum.
> > Does that still seem an acceptable cost, just to get systemtap to > > change its preferred kprobes api?
> [no answer]
Indeed.
- FChE
| |