[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Tue, Aug 26, 2008 at 10:35:05AM -0700, Linus Torvalds wrote:
> On Tue, 26 Aug 2008, Rusty Russell wrote:
> >
> > Your workaround is very random, and that scares me. I think a huge number of
> > CPUs needs a real solution (an actual cpumask allocator, then do something
> > clever if we come across an actual fastpath).
> The thing is, the inlining thing is a separate issue.
> Yes, the cpumasks were what made stack pressure so critical to begin with,
> but no, a 400-byte stack frame in a deep callchain isn't acceptable
> _regardless_ of any cpumask_t issues.
> Gcc inlining is a total and utter pile of shit. And _that_ is the problem.
> I seriously think we shouldn't allow gcc to inline anything at all unless
> we tell it to. That's how it used to work, and quite frankly, that's how
> it _should_ work.
> The downsides of inlining are big enough from both a debugging and a real
> code generation angle (eg stack usage like this), that the upsides
> (_somesimes_ smaller kernel, possibly slightly faster code) simply aren't
> relevant.
> It would be interesting to see what "-fno-default-inline" does to the
> kernel. It really would get rid of a _lot_ of gcc version issues too.
> Inlining behavior of gcc has long been a problem for us.

I added "-fno-inline-functions-called-once -fno-early-inlining" to
KBUILD_CFLAGS, and (with gcc 4.3) that increased the size of my kernel
image by 2%.

And when David's "-fwhole-program --combine" will become ready the cost
of disallowing gcc to inline functions will most likely increase.

A debugging option (for better traces) to disallow gcc some inlining
might make sense (and might even make sense for distributions to
enable in their kernels), but when you go to use cases that require
really small kernels the cost is too high.

But if you don't trust gcc's inlining you should revert
commit 3f9b5cc018566ad9562df0648395649aebdbc5e0 that increases gcc's
freedom regarding what to inline in 2.6.27 - what gcc 4.2 does in the
case of the regression tracked as Bugzilla #11276 is really not funny
(two callers -> function not inlined; gcc seems to emit the function
although both callers later get removed (or at least should be removed)
by dead code elimination).

> Linus



"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

 \ /
  Last update: 2008-08-26 20:35    [W:0.310 / U:0.884 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site