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 Tue, Oct 18, 2011 at 05:26:44PM -0700, Tim Bird wrote:
    > On 10/18/2011 05:14 PM, Joe Perches wrote:
    > > On Tue, 2011-10-18 at 16:27 -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').
    > >
    > > When 4k stacks went away, I thought it safe enough
    > > to submit vsnprintf recursion using %pV.
    > >
    > > I believe the current vsnprintf max recursion is 3.
    > > Each recursion uses at least 300 bytes of stack.
    > >
    > > That might be some additional issue for 4k stacks.
    >
    > Interesting. Thanks very much for the heads up.
    > I don't know how prevalent %pV is, but I'll take a
    > look tomorrow and see if I think this would be an
    > issue. One option would be to turn off recursion
    > in the 4K stacks case (but I don't know how badly
    > this would mangle the code).

    Badly.

    For example, every single message emitted by XFS uses %pV to add
    consistent message prefixes to the messages. See __xfs_printk().

    And a quick grep shows this same technique is used in ext3, ext4,
    NILFS, FAT and other filesystems, as well as netdev_printk,
    dev_printk, the libata code and more. IOWs, you'd basically break
    messages from most subsystems and drivers in the kernel...

    > I'm not sure I'm willing to advocate eliminating
    > all occurrences of high stack usage in the kernel.
    > It seems like this would generate a lot of friction
    > for getting this mainlined. As long as I can document
    > the trouble that people might get in when they
    > turn this on, I think that would be very good.

    "You can't use block based storage because the storage stack doesn't
    fit in 4k."

    > Even inside Sony, usage of 4K stacks is limited
    > to some very special cases, where memory is exceedingly
    > tight (we have one system with 4M of RAM). And we
    > don't mind lopping off features or coding around
    > problem areas to support our special case.

    Sounds to me like it's less overhead simply to maintain the patches
    for the systems that need it than it is to put it in mainline,
    document all the stuff that doesn't work and then, of course, have
    to triage all the problems people report because they haven't read
    the documentation.... :/

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com


    \
     
     \ /
      Last update: 2011-10-19 06:57    [W:4.245 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site