• M
    mm, memcg: use consistent gfp flags during readahead · 8a5c743e
    Michal Hocko 提交于
    Vladimir has noticed that we might declare memcg oom even during
    readahead because read_pages only uses GFP_KERNEL (with mapping_gfp
    restriction) while __do_page_cache_readahead uses
    page_cache_alloc_readahead which adds __GFP_NORETRY to prevent from
    OOMs.  This gfp mask discrepancy is really unfortunate and easily
    fixable.  Drop page_cache_alloc_readahead() which only has one user and
    outsource the gfp_mask logic into readahead_gfp_mask and propagate this
    mask from __do_page_cache_readahead down to read_pages.
    
    This alone would have only very limited impact as most filesystems are
    implementing ->readpages and the common implementation mpage_readpages
    does GFP_KERNEL (with mapping_gfp restriction) again.  We can tell it to
    use readahead_gfp_mask instead as this function is called only during
    readahead as well.  The same applies to read_cache_pages.
    
    ext4 has its own ext4_mpage_readpages but the path which has pages !=
    NULL can use the same gfp mask.  Btrfs, cifs, f2fs and orangefs are
    doing a very similar pattern to mpage_readpages so the same can be
    applied to them as well.
    
    [akpm@linux-foundation.org: coding-style fixes]
    [mhocko@suse.com: restrict gfp mask in mpage_alloc]
      Link: http://lkml.kernel.org/r/20160610074223.GC32285@dhcp22.suse.cz
    Link: http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
    Cc: Vladimir Davydov <vdavydov@parallels.com>
    Cc: Chris Mason <clm@fb.com>
    Cc: Steve French <sfrench@samba.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Mike Marshall <hubcap@omnibond.com>
    Cc: Jaegeuk Kim <jaegeuk@kernel.org>
    Cc: Changman Lee <cm224.lee@samsung.com>
    Cc: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    8a5c743e
extent_io.c 146.9 KB