Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Disable page allocation warnings for ARC buffers
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
ebcfc8a
There was a problem hiding this comment.
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:
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?
ebcfc8a
There was a problem hiding this comment.
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.