On 04/07/2015 08:40 AM, Ilya Dryomov wrote: > This reverts commit 89baaa570ab0b476db09408d209578cfed700e9f. > > Dirty page throttling should be sufficient for us in the general case > so there is no need to use __GFP_MEMALLOC - it would be needed only in > the swap-over-rbd case, which we currently don't support. (It would > probably take approximately the commit that is being reverted to add > that support, but we would also need the "swap" option to distinguish > from the general case and make sure swap ceph_client-s aren't shared > with anything else.) See ceph-devel threads [1] and [2] for the > details of why enabling pfmemalloc reserves for all cases is a bad > thing. > > On top of potential system lockups related to drained emergency > reserves, this turned out to cause ceph lockups in case peers are on > the same host and communicating via loopback due to sk_filter() > dropping pfmemalloc skbs on the receiving side because the receiving > loopback socket is not tagged with SOCK_MEMALLOC. > > [1] "SOCK_MEMALLOC vs loopback" > http://www.spinics.net/lists/ceph-devel/msg22998.html > [2] "[PATCH] libceph: don't set memalloc flags in loopback case" > http://www.spinics.net/lists/ceph-devel/msg23392.html > > Conflicts: > net/ceph/messenger.c [ context: tcp_nodelay option ] > > Cc: Mike Christie <micha...@cs.wisc.edu> > Cc: Mel Gorman <mgor...@suse.de> > Cc: Sage Weil <s...@redhat.com> > Cc: sta...@vger.kernel.org # 3.18+, needs backporting > Signed-off-by: Ilya Dryomov <idryo...@gmail.com>
Yeah, I misunderstood the memalloc flag use. Reviewed-by: Mike Christie <micha...@cs.wisc.edu> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
