diff options
author | Theodore Ts'o <tytso@mit.edu> | 2015-06-03 09:32:39 -0400 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2015-06-03 09:32:39 -0400 |
commit | 3dbb5eb9a3aa04f40e551338eee5e8d06f352fe8 (patch) | |
tree | c84bc425081af46b5692e437aa258adb0fe60846 /fs/ext4/mballoc.c | |
parent | e298e73bd766768707a7af440691ce2f418f5acc (diff) | |
download | op-kernel-dev-3dbb5eb9a3aa04f40e551338eee5e8d06f352fe8.zip op-kernel-dev-3dbb5eb9a3aa04f40e551338eee5e8d06f352fe8.tar.gz |
ext4 crypto: allocate bounce pages using GFP_NOWAIT
Previously we allocated bounce pages using a combination of
alloc_page() and mempool_alloc() with the __GFP_WAIT bit set.
Instead, use mempool_alloc() with GFP_NOWAIT. The mempool_alloc()
function will try using alloc_pages() initially, and then only use the
mempool reserve of pages if alloc_pages() is unable to fulfill the
request.
This minimizes the the impact on the mm layer when we need to do a
large amount of writeback of encrypted files, as Jaeguk Kim had
reported that under a heavy fio workload on a system with restricted
amounts memory (which unfortunately, includes many mobile handsets),
he had observed the the OOM killer getting triggered several times.
Using GFP_NOWAIT
If the mempool_alloc() function fails, we will retry the page
writeback at a later time; the function of the mempool is to ensure
that we can writeback at least 32 pages at a time, so we can more
efficiently dispatch I/O under high memory pressure situations. In
the future we should make this be a tunable so we can determine the
best tradeoff between permanently sequestering memory and the ability
to quickly launder pages so we can free up memory quickly when
necessary.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/mballoc.c')
0 files changed, 0 insertions, 0 deletions