Re: [PATCH] Deadlock during heavy write activity to userspace NFS server on local NFS mount

[Avi Kivity <avi@exanet.com>]

Nick Piggin wrote:

> Avi Kivity wrote:
>
>> Nick Piggin wrote:
>>
>>>
>>> There is some need arising for a call to set the PF_MEMALLOC flag for
>>> userspace tasks, so you could probably get a patch accepted. Don't
>>> call it KSWAPD_HELPER though, maybe MEMFREE or RECLAIM or 
>>> RECLAIM_HELPER.
>>
>>
>>
>> I don't think my patch is general enough, it deals with only one 
>> level of dependencies, and doesn't work if the NFS server (or other 
>> process that kswapd depends on) depends on kswapd itself. It was 
>> intended more as an RFC than a request for inclusion.
>>
>> It's probably fine for those with the exact same problem as us.
>>
>
> Well it isn't that you depend on kswapd, but that your task gets called
> into via page reclaim (to facilitate page reclaim). In which case having
> the task block in memory allocation can cause a deadlock.

In my particular case that's true, so I only depended on kswapd as a 
side effect of the memory allocation logic. Setting PF_MEMALLOC fixed that.

>
> The solution is that PF_MEMALLOC tasks are allowed to access the reserve
> pool. Dependencies don't matter to this system. It would be your job to
> ensure all tasks that might need to allocate memory in order to free
> memory have the flag set.

In the general case that's not sufficient. What if the NFS server wrote 
to ext3 via the VFS? We might have a ton of ext3 pagecache waiting for 
kswapd to reclaim NFS memory, while kswapd is waiting on the NFS server 
writing to ext3.

The patch I posted is simple and quite sufficient for my needs, but I'm 
sure more convoluted cases will turn up where something more complex is 
needed. Probably one can construct such cases out of in-kernel 
components like the loop device, dm, and the NFS client and server.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.