It is hard to follow exactly what this flag does in /mm (other than try harder on memory allocations) - I haven't found much about this flag (e.g. <a href="http://lwn.net/Articles/246928/">http://lwn.net/Articles/246928/</a>) but it does look like most of the fs no longer set this (except xfs) e.g. ext3_ordered_writepage. When running out of memory in the cifs_demultiplex_thread it will retry 3 seconds later, but if memory allocations ever fail in this path we could potentially be holding up (an already issued write in) writepages for that period by not having memory to get the response to see if the write succeeded.<br>
<br>We pass in few flags for these memory allocation requests: GFP_NOFS (on the mempool_alloc) and SLAB_HWCACHE_ALIGN (on the kmem_cache_create of the pool) should we be passing in other flags on the allocations?<br><br><div class="gmail_quote">
On Tue, Nov 17, 2009 at 6:47 AM, Jeff Layton <span dir="ltr"><<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue, 17 Nov 2009 16:22:32 +0900 (JST)<br>
KOSAKI Motohiro <<a href="mailto:kosaki.motohiro@jp.fujitsu.com">kosaki.motohiro@jp.fujitsu.com</a>> wrote:<br>
<br>
><br>
> Non MM subsystem must not use PF_MEMALLOC. Memory reclaim need few<br>
> memory, anyone must not prevent it. Otherwise the system cause<br>
> mysterious hang-up and/or OOM Killer invokation.<br>
><br>
> Cc: Steve French <<a href="mailto:sfrench@samba.org">sfrench@samba.org</a>><br>
> Cc: <a href="mailto:linux-cifs-client@lists.samba.org">linux-cifs-client@lists.samba.org</a><br>
> Cc: <a href="mailto:samba-technical@lists.samba.org">samba-technical@lists.samba.org</a><br>
> Signed-off-by: KOSAKI Motohiro <<a href="mailto:kosaki.motohiro@jp.fujitsu.com">kosaki.motohiro@jp.fujitsu.com</a>><br>
> ---<br>
> fs/cifs/connect.c | 1 -<br>
> 1 files changed, 0 insertions(+), 1 deletions(-)<br>
><br>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c<br>
> index 63ea83f..f9b1553 100644<br>
> --- a/fs/cifs/connect.c<br>
> +++ b/fs/cifs/connect.c<br>
> @@ -337,7 +337,6 @@ cifs_demultiplex_thread(struct TCP_Server_Info *server)<br>
> bool isMultiRsp;<br>
> int reconnect;<br>
><br>
> - current->flags |= PF_MEMALLOC;<br>
> cFYI(1, ("Demultiplex PID: %d", task_pid_nr(current)));<br>
><br>
> length = atomic_inc_return(&tcpSesAllocCount);<br>
<br>
</div></div>This patch appears to be safe for CIFS. I believe that the demultiplex<br>
thread only does mempool allocations currently. The only other case<br>
where it did an allocation was recently changed with the conversion of<br>
the oplock break code to use slow_work.<br>
<br>
Barring anything I've missed...<br>
<br>
Acked-by: Jeff Layton <<a href="mailto:jlayton@redhat.com">jlayton@redhat.com</a>><br>
</blockquote></div><br><br clear="all"><br>-- <br>Thanks,<br><br>Steve<br>