Skip to content

Commit

Permalink
Disable page allocation warnings for ARC buffers
Browse files Browse the repository at this point in the history
Buffers for the ARC are normally backed by the SPL virtual slab.
However, if memory is low, AND no slab objects are available,
AND a new slab cannot be quickly constructed a new emergency
object will be directly allocated.

These objects can be as large as order 5 on a system with 4k
pages.  And because they are allocated with KM_PUSHPAGE, to
avoid a potential deadlock, they are not allowed to initiate I/O
to satisfy the allocation.  This can result in the occasional
allocation failure.

However, since these allocations are allowed to block and
perform operations such as memory compaction they will eventually
succeed.  Since this is not unexpected (just unlikely) behavior
this patch disables the warning for the allocation failure.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #465
  • Loading branch information
behlendorf committed Sep 6, 2012
1 parent fc24f7c commit ebcfc8a
Showing 1 changed file with 3 additions and 2 deletions.
5 changes: 3 additions & 2 deletions module/zfs/zio.c
Original file line number Diff line number Diff line change
Expand Up @@ -259,7 +259,7 @@ zio_buf_alloc(size_t size)

ASSERT(c < SPA_MAXBLOCKSIZE >> SPA_MINBLOCKSHIFT);

return (kmem_cache_alloc(zio_buf_cache[c], KM_PUSHPAGE));
return (kmem_cache_alloc(zio_buf_cache[c], KM_PUSHPAGE | KM_NODEBUG));
}

/*
Expand All @@ -275,7 +275,8 @@ zio_data_buf_alloc(size_t size)

ASSERT(c < SPA_MAXBLOCKSIZE >> SPA_MINBLOCKSHIFT);

return (kmem_cache_alloc(zio_data_buf_cache[c], KM_PUSHPAGE));
return (kmem_cache_alloc(zio_data_buf_cache[c],
KM_PUSHPAGE | KM_NODEBUG));
}

void
Expand Down

2 comments on commit ebcfc8a

@chrisrd
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these allocation failures considered "mostly harmless" or "completely harmless", and how "unlikely" are they expected to be?

E.g. without this patch, minimal system/zfs turning (set zfs_arc_meta_limit to zfs_arc_max, no explicit vm.min_free_kbytes) and a light workload of a single receiving rsync and a simultaneous resilver:

Sep  8 01:46:19 b5 kernel: [47880.015793] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:46:21 b5 kernel: [47884.618058] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47892.526902] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47892.676713] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47892.845738] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47930.190093] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47930.349216] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47930.520605] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47930.719995] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47930.898777] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47931.378268] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47931.537419] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47931.667836] txg_sync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47931.717222] rsync: page allocation failure: order:5, mode:0x4030
Sep  8 01:50:54 b5 kernel: [47931.919181] rsync: page allocation failure: order:5, mode:0x4030

The box seemed to trundle along without any issues after this.

Given this patch makes the notifications go away altogether, are they completely uninteresting or is it worth leaving some kind of less-threatening notification in there?

@behlendorf
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are "completely harmless" in the sense that they are understood, expected to occur periodically, and as such are handled safely. Thus I feel they should be suppressed to ensure they never mask any more interesting unexpected failures which get logged to the console.

As mentioned previously, the only fix for this is to never do this sort of thing. That will address the root of the problem, but it's a ways off.

Please sign in to comment.