Re: Linux 2.6.7-rc2

From: Peter Osterlund (petero2_at_telia.com)
Date: 05/31/04

  • Next message: Jaroslav Kysela: "[PATCH] update to ALSA 1.0.5"
    To: Linus Torvalds <torvalds@osdl.org>
    Date:	31 May 2004 11:21:39 +0200
    
    

    Linus Torvalds <torvalds@osdl.org> writes:

    > Andrew Morton:
    > o Add `make checkstack' target

    The checkstack target itself works fine, but when I used it I found
    that nfs_writepage_sync and nfs_readpage_sync still use a lot of stack
    space:

    0xc01aae14 nfs_writepage_sync: 900
    0xc01a9492 nfs_readpage_sync: 872

    Apparently, this recent fix

            http://linux.bkbits.net:8080/linux-2.5/gnupatch@40ad0ce2ZBGzb_taAzCTOJ38IXxu-w

    doesn't really help, at least not with the compilers I have tested, ie
    gcc 3.3.3 from FC2 and the gcc from RH9.

    If I put "#if 0" around the *wdata assignment in nfs_writepage_sync,
    the stack usage goes down to 36, so it looks like gcc is building a
    temporary structure on the stack and then copies the whole thing to
    *wdata.

    Does this construct save stack space for any version of gcc? Maybe the
    code should be changed to do a memset() followed by explicit
    initialization of the non-zero member variables instead.

    #if 0
            *wdata = (struct nfs_write_data) {
                    .flags = how,
                    .cred = NULL,
                    .inode = inode,
                    .args = {
                            .fh = NFS_FH(inode),
                            .lockowner = current->files,
                            .pages = &page,
                            .stable = NFS_FILE_SYNC,
                            .pgbase = offset,
                            .count = wsize,
                    },
                    .res = {
                            .fattr = &wdata->fattr,
                            .verf = &wdata->verf,
                    },
            };
    #endif

    -- 
    Peter Osterlund - petero2@telia.com
    http://w1.894.telia.com/~u89404340
    -
    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/
    

  • Next message: Jaroslav Kysela: "[PATCH] update to ALSA 1.0.5"

    Relevant Pages

    • Re: [PATCH 00/14] GFS
      ... >> Please drop the extra braces. ... > Here and elsewhere we try to keep unused stuff off the stack. ... In practice gcc 3.x still adds up all the stack space ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: post 2.6.7 BK change breaks Java?
      ... argument frame on the stack. ... and there is no way to tell gcc that it is wrong. ... Personally, I think that if you wanted the callee to own the arguments, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RFC: i386: kill !4KSTACKS
      ... > any stack reduction patches in these areas. ... NFS patches were. ... gcc 3.4.3 can use excessive stack in degenerate cases, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Kernel 2.6.9 SCSI driver compile error w/gcc-3.4.2.
      ... drivers/scsi/cpqfcTScontrol.c:609:2: #error This is too much stack ... Thread model: posix ... gcc version 3.4.2 ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning
      ... Rigth now, it does sound like gcc simply doesn't try to balance AT ALL, or ... The gcc 4.3 inliner takes stack growth into account by default (without ... grow the static stack usage of the function we inline into, ... So "stop inlining when you hit a stack limit" IS THE WRONG THING TO ...
      (Linux-Kernel)