Bug#616401: linux-image-2.6.38-rc6-amd64: Please enable FTRACE_SYSCALLS
On Sun, Mar 13, 2011 at 12:55:13AM +0000, Ben Hutchings wrote:
> On Sat, 2011-03-12 at 16:37 -0800, Josh Triplett wrote:
> > On Sat, Mar 12, 2011 at 10:45:58PM +0000, Ben Hutchings wrote:
> > > On Thu, 2011-03-03 at 20:34 -0800, Josh Triplett wrote:
> > > > Package: linux-2.6
> > > > Version: 2.6.38~rc6-1~experimental.1
> > > > Severity: wishlist
> > > >
> > > > ~$ perf list | grep syscalls:
> > > > raw_syscalls:sys_enter [Tracepoint event]
> > > > raw_syscalls:sys_exit [Tracepoint event]
> > > >
> > > > Please consider enabling CONFIG_FTRACE_SYSCALLS, so perf can trace all
> > > > syscalls by name and decode them.
> > >
> > > This adds about 100K to the size of the kernel. I question whether this
> > > is worth the cost. Maybe for 64-bit architectures/flavours only?
> >
> > I don't see anywhere near that amount of overhead. I just checked, and
> > with current git master at least, CONFIG_FTRACE_SYSCALLS adds 30240
> > bytes to the size of bzImage.
>
> It selects various other options which I don't think we have enabled.
I started from defconfig, and turned on CONFIG_FTRACE_SYSCALLS from
there; the diff of .config showed only that one symbol turned on. What
does the .config diff look like for the Debian kernel?
> > I'd certainly consider that worth the benefit of having more of the
> > functionality of perf work out of the box.
>
> On a system with GBs of RAM, sure. Debian also runs on much smaller
> machine.
Architecture doesn't seem like a definitive check for target machine
memory size; all architectures can potentially get used on machines with
wildly varying characteristics. I've seen x86 systems with minimal RAM
and ARM systems with tons.
(Obviously, having this option enabled on x86-64 solves my problem, but
I'd tend to argue against diverging configurations between architectures
for any reason other than features not working/existing on the target
architecture.)
- Josh Triplett
Reply to: