filesystem behavior when low on memory and PF_MEMALLOC

[Steve French <smfltc@us.ibm.com>]

Does PF_MEMALLOC have a similar effect to setting SLAB_NOFS and
equivalent on memory allocations? and prevent memory allocations in
critical code paths from blocking?

Sergey Vlasov recently made a good suggestion about fixing a problem
with very large file copy hangs via the use of the PF_MEMALLOC.

He noted that shrink_caches can cause writepage (cifs_writepage in my
case) to be invoked to write out dirty pages - but writepage needs to
allocate memory both explicitly (for each the 4.5K cifs write buffer)
and implicitly as a result of using the sockets API (sock_sendmsg can
allocate memory) but this presumably can block.  In addition the cifs
demultiplex thread needs to get an acknowledgement from the server to
before waking up the writepage thread - but the demultiplex thread can
allocate memory in some cases.

His suggested solution was to add the PF_MEMALLOC flag to the
current->flags for the demultiplex thread, which makes sense and seems
similar to what XFS and a few other filesystems do in some of their
daemons.   What was harder to evaluate though was how to fix the context
of the process doing writepage - is it ok to temporarily set PF_MEMALLOC
on entry to a filesystems writepage and writepages routines? Or would
this be redundant since the linux/mm code should already be doing this
in all low memory paths in the calling function? Is it ok to clear the
flag - always clearing PF_MEMALLOC on exit from cifs_writepage (and
eventually cifs_writepages when that is added).  The alternative is to
set SLAB_NOFS and equivalent on memory allocations on all calls in cifs
on behalf of writepages which would probably be ok but would hit more
code and make the codepaths trickier (figuring out if an smb buffer
allocation e.g. came from writepage).  My initial observations was that
there is a significant performance hit setting SLAB_NOFS on all cifs
buffer allocations (although I think that this is what at least one
other filesystem basically does) - it seems like overkill when writepage
(and possibly prepare_write/commit_write) are the ones that matter for
performance during low memory situations as pages are being freed.