David reported that following the async cow path refactoring that got into
misc-next he started seeing premature OOM kills due to large page allocations
(order 4). This was due to now the whole async context (alongisde ancillary
structures, describing chunks) being allocated in a single kmalloc call. The
first patch of this series aims to fix that by converting the kmalloc call to
kvmalloc. This will have virtually no perfromance impact for small writes and
for larger ones will fallback to vmalloc.
However, while testing the first patch I observed BUG_ONs in the async
csum calculation path to trigger. This is clearly caused by the fact that
the first patch introduces a fairly large memory allocation. Nevertheless,
having large allocations in the csum path without a fallback to some sort of
order 0 page allocation or at least graceful handling of memory errors is gross.
Patch 2 aims to rectify this by switching the allocation in btrfs_csum_one_bio
to using kvmalloc, giving greated chance for success. Even if patch 1 is ignored
nothing prevents the csum calculation to trigger the bug on depending on the
memory
usage/fragmentation of the server so IMO it's beneficial either ways.
Nikolay Borisov (2):
btrfs: Use kvmalloc for allocating compressed path context
btrfs: Switch memory allocations in async csum calculation path to
kvmalloc
fs/btrfs/file-item.c | 15 +++++++++++----
fs/btrfs/inode.c | 9 +++++++--
fs/btrfs/ordered-data.c | 3 ++-
3 files changed, 20 insertions(+), 7 deletions(-)
--
2.17.1
