lkml.org 
[lkml]   [2008]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
    On Thu, Aug 28, 2008 at 01:00:52AM +0900, Paul Mundt wrote:
    > On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote:
    > > On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote:
    > > > On Wed, 27 Aug 2008, Adrian Bunk wrote:
    > > > >
    > > > > When did we get callpaths like like nfs+xfs+md+scsi reliably
    > > > > working with 4kB stacks on x86-32?
    > > >
    > > > XFS may never have been usable, but the rest, sure.
    > > >
    > > > And you seem to be making this whole argument an excuse to SUCK, adn an
    > > > excuse to let gcc crap even more on our stack space.
    > > >
    > > > Why?
    > > >
    > > > Why aren't you saying that we should be able to do better? Instead, you
    > > > seem to asking us to do even worse than we do now?
    > >
    > > My main point is:
    > > - getting 4kB stacks working reliably is a hard task
    > > - having an eye on gcc increasing the stack usage, and fixing it if
    > > required, is relatively easy
    > >
    > > If we should be able to do better at getting (and keeping) 4kB stacks
    > > working, then coping with possible inlining problems caused by gcc
    > > should not be a big problem for us.
    > >
    > Out of the architectures you've mentioned for 4k stacks, they also tend
    > to do IRQ stacks, which is something you seem to have overlooked.

    No, I am aware of that, and on i386 IRQ stacks are only used with
    4kB stacks.

    On i386 it is effectively a step from 6kB to 4kB.

    > In addition to that, debugging the runaway stack users on 4k tends to be
    > easier anyways since you end up blowing the stack a lot sooner. On sh
    > we've had pretty good luck with it, though most of our users are using
    > fairly deterministic workloads and continually profiling the footprint.
    > Anything that runs away or uses an insane amount of stack space needs to
    > be fixed well before that anyways, so catching it sooner is always
    > preferable. I imagine the same case is true for m68knommu (even sans IRQ
    > stacks).

    CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
    wanted with an arbitrary limit.

    > Things might be more sensitive on x86, but it's certainly not something
    > that's a huge problem for the various embedded platforms to wire up,
    > whether they want to go the IRQ stack route or not.

    How many platforms use 4kB stacks on sh?

    Only 1 out of 34 defconfigs uses it.

    Are there any numbers for real life usage.

    > In any event, lack of support for something on embedded architectures in
    > the kernel is more often due to apathy/utter indifference on the part of
    > the architecture maintainer rather than being indicative of any intrinsic
    > difficulty in supporting the thing in question. Most new "features" on the
    > lesser maintained architectures tend to end up there either out of peer
    > pressure or copying-and-pasting accidents rather than any sort of design.
    > ;-)

    arm or powerpc aren't exactly lesser maintained architectures.

    4kB has shown to be a hard to achieve limit. After more than 4 years in
    mainline being available on i386 there are still cases where 4kB are not
    enough.

    IMHO there seems to currently be a mismatch between it's maintainance
    cost and the actual number of users. That's in my opinion the main
    problem with it, no matter in which direction it gets resolved.

    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



    \
     
     \ /
      Last update: 2008-08-27 19:39    [W:0.025 / U:30.684 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site