On Mon, Jul 23, 2007 at 02:28:11PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 23 Jul 2007, Andrew Morton wrote:
> >
> > It'd be nice to get a clean trace. Are you able to obtain the full
> > trace with CONFIG_FRAME_POINTER=y?
>
> If you are talking about
>
> http://userweb.kernel.org/~akpm/dsc03659.jpg
>
> then I think that _is_ a full trace. It's certainly not very messy, and it
> seems accurate. It's just that inlining makes it much harder to see the
> call-graphs, but that's what inlining does..
>
> For example, missing from the call graph is
>
> get_page_from_freelist ->
> buffered_rmqueue -> [ missing - inlined ]
> prep_new_page -> [ missing - inlined ]
> prep_zero_page -> [ missing - inlined ]
> clear_highpage -> [ missing - inlined ]
> kmap_atomic -> [ missing - tailcall ]
> kmap_atomic_prot
>
> but I'm pretty sure the call trace is good (and I'm also pretty sure gcc
> is overly aggressive at inlining, and that it causes us pain for
> debugging, but whatever)
>...
For prep_zero_page() and clear_highpage() we can't blame gcc since we
force gcc to always inline them.
buffered_rmqueue() and prep_new_page() are static functions with only
one caller each, and for the normal non-debug case it's a really nice
optimization to have them inlined automatically. But it might make sense
to add -fno-inline-functions-called-once to the CFLAGS depending on some
debug option?
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
