On Fri, Dec 03, 2004 at 05:18:35PM +1100, Nathan Scott wrote:
> OK, I took a quick look through - there's two places where we use
> GFP_ATOMIC at the moment. One is a log debug/tracing chunk of code,
> wont be coming into play here, I'll go back and rework that later.
> The second is in the metadata buffering code, and is in a spot where
> we can cope with a failure (don't need to dip into emergency pools
> at all) but looks like we're avoiding sleeping there.
>
> Does this patch improve things for your workload, Stefan?
This change leads to:
Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 2176 of file fs/x
fs/xfs_da_btree.c. Caller 0xc0200641
[<c02003da>] xfs_da_do_buf+0x72a/0x8df
[<c0200641>] xfs_da_read_buf+0x57/0x5b
[<c023e16c>] kmem_zone_alloc+0x50/0x96
[<c01fe46c>] xfs_da_node_lookup_int+0x80/0x369
[<c0200641>] xfs_da_read_buf+0x57/0x5b
[<c02090e4>] xfs_dir2_leafn_lookup_int+0x381/0x551
[<c02090e4>] xfs_dir2_leafn_lookup_int+0x381/0x551
[<c01fe5f6>] xfs_da_node_lookup_int+0x20a/0x369
[<c020ae13>] xfs_dir2_node_lookup+0x3f/0xb9
[<c0202725>] xfs_dir2_lookup+0x13e/0x14e
[<c0168342>] update_atime+0xd0/0xd5
[<c0131f02>] do_generic_mapping_read+0x2bc/0x53f
[<c02333e2>] xfs_dir_lookup_int+0x4c/0x12b
[<c0238bd5>] xfs_lookup+0x50/0x88
[<c0244ff0>] linvfs_lookup+0x58/0x96
[<c015bd7e>] real_lookup+0xcd/0xf0
[<c015bff4>] do_lookup+0x96/0xa1
[<c015c692>] link_path_walk+0x693/0xd13
[<c015cfbe>] path_lookup+0x93/0x155
[<c015d674>] open_namei+0x85/0x60c
[<c014dcd1>] filp_open+0x3e/0x64
[<c014ea08>] vfs_read+0xc9/0x119
[<c014dfac>] get_unused_fd+0x7b/0xcf
[<c014e0f4>] sys_open+0x49/0x89
[<c0103fcf>] syscall_call+0x7/0xb
xfs_da_do_buf: bno 96
--
Lukáš Hejtmánek
|