Re: [PATCH] Deadlock during heavy write activity to userspace NFSserver on local NFS mount
From: Avi Kivity
Date: Wed Jul 28 2004 - 02:07:22 EST
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/