[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, 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

    So the "noinline" was random, yes, but this is a real issue. Looking at
    checkstack output for a saner config (NR_CPUS=16), the top entries for me
    are things like

    ide_generic_init [vmlinux]: 1384
    idefloppy_ioctl [vmlinux]: 1208
    e1000_check_options [vmlinux]: 1152

    which are "leaf" functions. They are broken as hell (the e1000 is
    apparently because it builds structs on the stack that should all be
    "static const", for example), but they are different from something like
    the module init sequence in that they are not going to affect anything

    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.


     \ /
      Last update: 2008-08-26 19:37    [W:0.021 / U:103.684 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site