lkml.org 
[lkml]   [2011]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] ARM 4Kstacks: introduction
    On 10/19/2011 12:35 AM, Russell King - ARM Linux wrote:
    > On Tue, Oct 18, 2011 at 04:27:45PM -0700, Tim Bird wrote:
    >> I'm about to submit a set of patches (really pretty small)
    >> to add 4K stack support to ARM (defaulted to 'N').
    >>
    >> This has been kicking around in my Sony tree for a few years,
    >> and it's about time to mainline it. The first patch is
    >> the actual 4KSTACKS patch. See subsequent patches
    >> for tools to help with stack reduction to avoid the problems
    >> that apparently led to the removal of this feature on x86.
    >
    > This isn't a good idea - if the feature has been abandoned on x86,
    > people aren't going to be soo concerned about the stack usage of
    > each function. They're going to accept that there's more stack
    > space available, and we'll see code paths that start expecting that.

    Well, the difference in size is not an order of magnitude. Current
    stacks are only twice as big as what this feature optionally allows.
    So people really shouldn't go crazy with their stack usage.

    Granted we're already seeing a bit of stack bloat, but IMHO this should
    be nipped in the bud. If the stack grows a lot more, it will likely
    need to shift to 16K, which would REALLY be costly on machines
    with lots of threads and low memory.

    I don't want to give up on a small-footprint Linux so easily,
    and the discipline for keeping stacks small is probably good
    for code hygiene anyway.

    > If we switch to 4K stacks, the problems of stack usage become ours.
    > Do we have the capacity to be able to address these issues as they
    > crop up?

    Since it's optional, it would become the problem of the people
    who actually use the option. If you think tracking down stack
    abusers is going to be a pain, just don't do it.

    If I do it, and get pushback, then I'll make the case to individual
    function authors, and we'll see what happens from there. As it is,
    this patch has been useful for me, and continues to be useful
    even in the current kernel version, with no other changes
    required in mainline.

    Having said this, I've written a tool to rather easily identify
    the functions which use the most stack, and so far the routines
    I've looked at have had rather simple solutions. It almost always
    boils down to a single big data item on the stack.

    I can understand if people don't want to take patches which
    unconditionally limit their stack usage - especially if there's
    a performance impact. But I don't see much rationale for not
    limiting their stack usage conditionally (that is, do something
    slightly different on #ifdef CONFIG_4KSTACKS). If people
    object to even that, then I'll maintain those patches out of
    tree, if they're really needed.

    Once again, our products work even without such patches now,
    based on the configs we're using and the user-space we're running.
    Note that this is defaulted to 'N', so no one should be negatively
    affected unless they opt in.

    So, I understand your point. I would, however, like to have
    this patch applied, and then deal with any problems as they
    come up, rather than preemptively kill the feature on speculative
    problems.
    -- Tim

    =============================
    Tim Bird
    Architecture Group Chair, CE Workgroup of the Linux Foundation
    Senior Staff Engineer, Sony Network Entertainment
    =============================



    \
     
     \ /
      Last update: 2011-10-20 01:39    [W:0.039 / U:120.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site