Re: [tip:tracing/urgent] tracing: Fix too large stack usage in do_one_initcall()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 21 Aug 2009, Ingo Molnar wrote:
> > 
> > That's why I think the async thing could fix this - if we _force_ 
> > async calls to be asynchronous, you won't have the deep callchains 
> > for all the device discovery thing.
> 
> Agreed. OTOH we have deep callchains in things like execve() too 
> which seem to be a lot harder to fix - and those have been around 
> for the past ~10 years since i've been looking at max-stacktraces.
> I think 4K doesnt cut it anymore.

I agree that we have stack traces that are too deep in other areas too. At 
the same time, it does tend to be the case that initcalls are special due 
to having those long chains of detection (PCI -> driver -> bus -> device), 
so targeting them specially is probably a good idea. 

(There are other "special" chains that tend to be long, like "mount": 
you often end up doing things like reading root inode information etc down 
a fairly deep chain).

And we probably should really complain more actively about big stack 
frames. We have that CONFIG_FRAME_WARN thing, but it's set very high. 

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux