lkml.org 
[lkml]   [2004]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [STACK] >3k call path in xfs
    Jörn Engel wrote:
    > xfs is quite interesting. No single function is particularly
    > stack-hungry, but the sheer depth of the call path adds up. Nathan,
    > can you see if some bytes can be saved here and there?
    >
    > 3k is not really bad yet, I just like to keep 1k of headroom for
    > surprises like an extra int foo[256] in a structure.

    Are you doing some form of call chain analysis to arrive
    at this stack?

    Actually this one is impossible, the function xfs_bmapi is
    confusing you analyser, it is used for read and write
    calls to map from file offsets to disk blocks. The path
    you chased down from xfs_bmapi is doing a realtime
    allocation, the swapext call does not do allocations,
    it is in this case looking up the contents of an acl
    for a permission check - xfs_bmapi in this case will
    not call much of anything.

    The bmapi path you did follow, for an allocation in a
    realtime file, is doing a read of the realtime bitmap
    inode which holds the layout of the realtime component
    of the filesystem.

    Once it gets to schedule it is a little out of XFS's hands what
    happens, or which stack is actually in use. I think the
    path you followed out of schedule is the cleanup of the
    audit structure of a dead process - it is the one doing
    the panicing here. An xfs call into schedule to wait for
    I/O will not be going down that path.

    I think you have to be careful looking at these call chains.

    Steve

    >
    > stackframes for call path too long (3064):
    > size function
    > 144 xfs_ioctl
    > 328 xfs_swapext
    > 0 xfs_iaccess
    > 16 xfs_acl_iaccess
    > 104 xfs_attr_fetch
    > 0 xfs_attr_node_get
    > 28 xfs_da_node_lookup_int
    > 68 xfs_dir2_leafn_lookup_int
    > 0 xfs_da_read_buf
    > 288 xfs_bmapi
    > 52 xfs_rtpick_extent
    > 24 xfs_trans_iget
    > 32 xfs_iget
    > 32 xfs_iread
    > 72 xfs_itobp
    > 60 xfs_imap
    > 84 xfs_dilocate
    > 0 xfs_inobt_lookup_le
    > 16 xfs_inobt_increment
    > 28 xfs_btree_readahead_core
    > 20 xfs_btree_reada_bufl
    > 12 pagebuf_readahead
    > 16 pagebuf_get
    > 0 pagebuf_iostart
    > 0 xfs_bdstrat_cb
    > 68 pagebuf_iorequest
    > 0 pagebuf_iodone
    > 0 pagebuf_iodone_work
    > 0 pagebuf_rele
    > 0 preempt_schedule
    > 84 schedule
    > 16 __put_task_struct
    > 20 audit_free
    > 36 audit_log_start
    > 16 __kmalloc
    > 0 __get_free_pages
    > 28 __alloc_pages
    > 284 try_to_free_pages
    > 0 out_of_memory
    > 0 mmput
    > 16 exit_aio
    > 0 __put_ioctx
    > 16 do_munmap
    > 0 split_vma
    > 36 vma_adjust
    > 0 fput
    > 0 __fput
    > 0 locks_remove_flock
    > 12 panic
    > 0 sys_sync
    > 0 sync_inodes
    > 308 sync_inodes_sb
    > 0 do_writepages
    > 128 mpage_writepages
    > 4 write_boundary_block
    > 0 ll_rw_block
    > 28 submit_bh
    > 0 bio_alloc
    > 88 mempool_alloc
    > 256 wakeup_bdflush
    > 20 pdflush_operation
    > 0 printk
    > 16 release_console_sem
    > 16 __wake_up
    > 0 printk
    > 0 vscnprintf
    > 32 vsnprintf
    > 112 number
    >
    > Jörn
    >

    -
    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-03-22 14:03    [W:2.673 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site