Re: [RFC] systemtap: begin the process of using proper kernel APIs(part1: use kprobe symbol_name/offset instead of address)
From: Andi Kleen
Date: Fri Jul 18 2008 - 06:31:26 EST
> 1) stap ought to use the kernel's infrastructure and not re-implement
> its own.
> 2) if the kernel's infrastructure doesn't meet requirements, improve
No argument on either of those. Right now the kernel infrastructure
is only comparable to what systemtap overs at very high overhead
costs (see below)
> But while the x86 might not be perfect, its fairly ok these days. Its
> not the utter piece of shite x86_64 had for a long time
Not sure what you're referring to with this. AFAIK the x86-64 unwinder
for a normal frame pointer less kernel was not any worse (or better)
than a i386 kernel without frame pointers.
- today's traces
> mostly make sense.
If you enable frame pointers? Making your complete kernel slower?
Generating much worse code on i386 by wasting >20% of its available
registers? Getting pipeline stalls on each function call/exit on many CPUs?
Right now unfortunately there are a few rogue CONFIGs who select that
so more and more kernels have, but I found that always distateful because
enabling frame pointers has such a large impact on all kernel code, especially
on the register starved i386.
I still think the right solution eventually is to have a dwarf2 unwinder
by default for i386/x86-64 and get rid of all these nasty "select
FRAME_POINTER"s which have unfortunately sneaked in.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/