On 03/04/2015 02:04 PM, Mel Gorman wrote: > On Wed, Mar 04, 2015 at 09:38:48PM +0300, Ilya Dryomov wrote: >> Hello, >> >> A short while ago Mike added a patch to libceph to set SOCK_MEMALLOC on >> libceph sockets and PF_MEMALLOC around send/receive paths (commit >> 89baaa570ab0, "libceph: use memalloc flags for net IO"). rbd is much >> like nbd and is succeptible to all the same memory allocation >> deadlocks, so it seemed like a step in the right direction. >> > > The contract for SOCK_MEMALLOC is that it would only be used for temporary > allocations that were necessary for the system to make forward progress. In > the case of swap-over-NFS, it would only be used for transmitting > buffers that were necessary to write data to swap when there were no Are upper layers like NFS/iSCSI/NBD/RBD supposed to know or track when there are no other options (for example if a GFP_ATOMIC allocation fails, then set the flags and retry the operation), or are they supposed to be able to set the flags, send IO and let the network layer handle it? > other options. If that contract is not met then using it can deadlock the > system. It's the same for PF_MEMALLOC -- activating that is a recipe for > deadlock due to memory exhaustion. For rbd and iscsi's SOCK_MEMALLOC/PF_MEMALLOC use, I copied what you did for nbd in commit 7f338fe4540b1d0600b02314c7d885fd358e9eca which always sets those flags and seems to rely on the network layer to do the right thing. Are they all incorrect? -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
