[lkml]   [2005]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [2.6 patch] i386: always use 4k stacks
    On Fri, Dec 16, 2005 at 01:56:58PM +1100, Neil Brown wrote:
    > On Thursday December 15, wrote:
    > > On Fri, Dec 16, 2005 at 01:47:40AM +0100, Adrian Bunk wrote:
    > >
    > > > > [*] Plus a few XFS ones, but that's been a lost cause wrt stack usage
    > > > > for a long time -- people were reporting overflows there before we
    > > > > enabled 4K stacks.
    > > >
    > > > I remember someone from the XFS maintainers (Nathan?) saying they
    > > > believe having solved all XFS stack issues.
    > > >
    > > > If there are any XFS issues left, do you have a pointer to them?
    > >
    > > The last one I saw may have been actually been more related
    > > to the block layer problem. iirc that was a user NFS exporting
    > > XFS on a raid1 array.
    > Yeh, I've noticed that nfsd seems to figure often in these. As nfsd
    > lives on the same (in-kernel) stack as the filesystem and device
    > drives, it will add a couple of hundred bytes to the call trace.
    > A typical nfsd call trace is
    > nfsd -> svc_process -> nfsd_dispatch -> nfsd3_proc_write ->
    > nfsd_write ->nfsd_vfs_write -> vfs_writev
    > (errr. nfsd_vfs_write is inline, large, and called twice, that ain't
    > good)

    The nfsd code uses inline in too many places.

    gcc can figure out itself that static functions called only once should
    be inline (except currently on i386 due to no-unit-at-a-time, see

    > These add up to over 300 bytes on the stack.
    > Looking at each of these, I see that nfsd_write (which includes
    > nfsd_vfs_write) contributes 0x8c to stack usage itself!!
    > It turns out this is because it puts a 'struct iattr' on the stack so
    > it can kill suid if needed. The following patch saves about 50 bytes
    > off the stack in this call path.

    This works currently on i386 (and only on i386) because we are using
    -fno-unit-at-a-time there.

    In the medium-term, we want to get rid of no-unit-at-a-time because this
    makes the code both bigger and slower, and I'm therefore not a big fan
    of this kind of workarounds.

    If this struct is really a problem (which I doubt considering it's
    size), I'd prefer it being kmalloc'ed.

    > NeilBrown



    "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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-16 13:20    [W:0.026 / U:0.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site