Return-Path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:35175 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752685AbcDZL4X (ORCPT ); Tue, 26 Apr 2016 07:56:23 -0400 From: Michal Hocko To: , Cc: Andrew Morton , Dave Chinner , "Theodore Ts'o" , Chris Mason , Jan Kara , ceph-devel@vger.kernel.org, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, logfs@logfs.org, xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mtd@lists.infradead.org, reiserfs-devel@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, linux-f2fs-devel@lists.sourceforge.net, linux-afs@lists.infradead.org, LKML Subject: [PATCH 0/2] scop GFP_NOFS api Date: Tue, 26 Apr 2016 13:56:10 +0200 Message-Id: <1461671772-1269-1-git-send-email-mhocko@kernel.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: Hi, we have discussed this topic at LSF/MM this year. There was a general interest in the scope GFP_NOFS allocation context among some FS developers. For those who are not aware of the discussion or the issue I am trying to sort out (or at least start in that direction) please have a look at patch 1 which adds memalloc_nofs_{save,restore} api which basically copies what we have for the scope GFP_NOIO allocation context. I haven't converted any of the FS myself because that is way beyond my area of expertise but I would be happy to help with further changes on the MM front as well as in some more generic code paths. Dave had an idea on how to further improve the reclaim context to be less all-or-nothing wrt. GFP_NOFS. In short he was suggesting an opaque and FS specific cookie set in the FS allocation context and consumed by the FS reclaim context to allow doing some provably save actions that would be skipped due to GFP_NOFS normally. I like this idea and I believe we can go that direction regardless of the approach taken here. Many filesystems simply need to cleanup their NOFS usage first before diving into a more complex changes. The patch 2 is a debugging aid which warns about explicit allocation requests from the scope context. This is should help to reduce the direct usage of the NOFS flags to bare minimum in favor of the scope API. It is not aimed to be merged upstream. I would hope Andrew took it into mmotm tree to give it linux-next exposure and allow developers to do further cleanups. There is a new kernel command line parameter which has to be used for the debugging to be enabled. I think the GFP_NOIO should be seeing the same clean up. Any feedback is highly appreciated.