lkml.org 
[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectStack usage tasks
    On Thu, Mar 31, 2005 at 05:05:48PM +0200, Jörn Engel wrote:
    > On Wed, 30 March 2005 23:39:40 -0800, Yum Rayan wrote:
    > >
    > > Before patch
    > > ------------
    > > check_free_space - 128
    > > do_acct_process - 105
    > >
    > > After patch
    > > -----------
    > > check_free_space - 36
    > > do_acct_process - 44
    >
    > It is always nice to see enthusiams, but in your case it might be a
    > bit misguided. None of the functions you worked on appear to be real
    > problems wrt. stack usage.
    >
    > But if you have time to tackle some of these functions, that may make
    > a real difference:
    >
    > http://wh.fh-wedel.de/~joern/stackcheck.2.6.11
    >
    > In principle, all recursive paths should consume as little stack as
    > possible. Or the recursion itself could be avoided, even better. And

    Sometimes it's easy to prove that the recursion can't occur more than
    once.

    Especially with a moderate stack usage, such cases are not a problem.

    But auditing the recursive paths for problematic ones is still an open
    task.

    > some of the call chains with ~3k of stack consumption may be
    > problematic on other platforms, like the x86-64. Taking care of those
    > could result in smaller stacks for the respective platform.

    There's also something different that can be done:

    On i386, unit-at-a-time is disabled (the only currently released version
    of GNU gcc with unit-at-a-time is gcc 3.4 [1]) since gcc's stack
    handling isn't very good.

    With unit-at-a-time, the highest stack usage within a single function is
    over 3kB.

    While this is technically gcc's fault, workarounds were IMHO worth it
    since unit-at-a-time gives me kernel images that are smaller by 2% [2]
    and I was surprised if the speed effect wasn't positive [3].

    The task I'm suggesting was therefore:
    - remove the -fno-unit-at-a-time in arch/i386/Makefile in your private
    kernel sources
    - use gcc 3.4
    - reduce the stack usages in call paths > 3kB

    Note that with unit-at-a-time, gcc inline several static functions, so
    the stack usage you see for a function might be accumulated from several
    functions.

    It's IMHO the best doing this against -mm.

    I do currently not have the time for doing this, but it was something
    with a real advantage for many users.

    > Jörn

    cu
    Adrian

    [1] SuSE "gcc 3.3" also supports this
    [2] with -O2
    [3] I do not claim it has to be measurable positive, but at least not
    negative

    --

    "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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:0.024 / U:119.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site