Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp3527160pxb; Sun, 26 Sep 2021 18:26:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxuJDYY44dMOnW3+CiM6oAB6XWGCruV0wgPU5/7kvAwhncLhBMfAQS0fZjZg6O+3L99Ej3h X-Received: by 2002:a17:90b:f8f:: with SMTP id ft15mr717307pjb.217.1632705961608; Sun, 26 Sep 2021 18:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632705961; cv=none; d=google.com; s=arc-20160816; b=hv5t5+bHfzTEbdAAy95aZj/jP8m4t9h/vt54GscoI+m1bH2di+0FRoTbni1W+WShHC yLEj2zmCSw79+BQK3qtktDO89FsZpNGkY1cgQUY/UFnjfHeji4VCop7fcPkmHjNSdmfB QYY0ud/Y46HFLVB78+nkaNvAdN3hE7S9UP4lv/ON1lUclUN6ViMj5AbzR7TioLyQuA+u v+b5bFOc0ILnY7n0JtTjwEFBsFSnYYpSYl1PpCl8ZFEoqIsZ3rS36fDtiMWU0f8XdYzD Pw2aLJ6zTfbf42HgyDRoklv6yGNcPoLvaMCmZ3OWjmzvW+7GlLEqLYy6OBf2nkfxRVd3 tgXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=OkYzrTjxaK4/97lVkD5tUP7W2GuwMzg1OMVcsbSxbuU=; b=TWE7Vd40OKaEJ/KZOlzi0JuboJEb23eX5vZ2sIPilQvFKz3osbWqND+FdAW2ldcIQ1 WW5zJVB+fyWRfwl7wwNlVbVHJMZjK948P1BtBqQ/fUkPZd9AlW2E6p/XLI29HHACsHwO +CdQ2VuAhyUawIeQBwNqYALBmDPXZDIoRqdTiJgZEhR3N+5pHWLUC/ykmEDWGiPCKbtG c7TviKX8YBPkQb3h0VO0jw2vKRyRXoCo/1GlY1TIZA1cNjcgFREEQyKn8v7tnR9HNS6Q V7v5isLL3NAEOgr1U6yhncTcovWDMjEzEiNbnFANe4wBAe0WzKcu37pyX7v5c51/HZkc esuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s7si2572967pjl.27.2021.09.26.18.25.36; Sun, 26 Sep 2021 18:26:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232331AbhI0B1K (ORCPT + 99 others); Sun, 26 Sep 2021 21:27:10 -0400 Received: from mail107.syd.optusnet.com.au ([211.29.132.53]:45811 "EHLO mail107.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232246AbhI0B1J (ORCPT ); Sun, 26 Sep 2021 21:27:09 -0400 Received: from dread.disaster.area (pa49-195-238-16.pa.nsw.optusnet.com.au [49.195.238.16]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 1969EA6C1; Mon, 27 Sep 2021 11:25:27 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1mUfOZ-00H8ch-4e; Mon, 27 Sep 2021 11:25:27 +1000 Date: Mon, 27 Sep 2021 11:25:27 +1000 From: Dave Chinner To: Damien Le Moal Cc: Matthew Wilcox , David Howells , hch@lst.de, trond.myklebust@primarydata.com, Jens Axboe , "Darrick J. Wong" , linux-block@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, darrick.wong@oracle.com, viro@zeniv.linux.org.uk, jlayton@kernel.org, torvalds@linux-foundation.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 9/9] mm: Remove swap BIO paths and only use DIO paths Message-ID: <20210927012527.GF1756565@dread.disaster.area> References: <163250387273.2330363.13240781819520072222.stgit@warthog.procyon.org.uk> <163250396319.2330363.10564506508011638258.stgit@warthog.procyon.org.uk> <2396106.1632584202@warthog.procyon.org.uk> <5fde9167-6f8b-c698-f34d-d7fafd4219f7@opensource.wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fde9167-6f8b-c698-f34d-d7fafd4219f7@opensource.wdc.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=YKPhNiOx c=1 sm=1 tr=0 a=DzKKRZjfViQTE5W6EVc0VA==:117 a=DzKKRZjfViQTE5W6EVc0VA==:17 a=kj9zAlcOel0A:10 a=7QKq2e-ADPsA:10 a=JfrnYn6hAAAA:8 a=7-415B0cAAAA:8 a=9mJ4K6JeBK9rWth2XkwA:9 a=CjuIK1q_8ugA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Sep 27, 2021 at 08:08:53AM +0900, Damien Le Moal wrote: > On 2021/09/26 2:09, Matthew Wilcox wrote: > > On Sat, Sep 25, 2021 at 04:36:42PM +0100, David Howells wrote: > >> Matthew Wilcox wrote: > >> > >>> On Fri, Sep 24, 2021 at 06:19:23PM +0100, David Howells wrote: > >>>> Delete the BIO-generating swap read/write paths and always use ->swap_rw(). > >>>> This puts the mapping layer in the filesystem. > >>> > >>> Is SWP_FS_OPS now unused after this patch? > >> > >> Ummm. Interesting question - it's only used in swap_set_page_dirty(): > >> > >> int swap_set_page_dirty(struct page *page) > >> { > >> struct swap_info_struct *sis = page_swap_info(page); > >> > >> if (data_race(sis->flags & SWP_FS_OPS)) { > >> struct address_space *mapping = sis->swap_file->f_mapping; > >> > >> VM_BUG_ON_PAGE(!PageSwapCache(page), page); > >> return mapping->a_ops->set_page_dirty(page); > >> } else { > >> return __set_page_dirty_no_writeback(page); > >> } > >> } > > > > I suspect that's no longer necessary. NFS was the only filesystem > > using SWP_FS_OPS and ... > > > > fs/nfs/file.c: .set_page_dirty = __set_page_dirty_nobuffers, > > > > so it's not like NFS does anything special to reserve memory to write > > back swap pages. > > > >>> Also, do we still need ->swap_activate and ->swap_deactivate? > >> > >> f2fs does quite a lot of work in its ->swap_activate(), as does btrfs. I'm > >> not sure how necessary it is. cifs looks like it intends to use it, but it's > >> not fully implemented yet. zonefs and nfs do some checking, including hole > >> checking in nfs's case. nfs also does some setting up for the sunrpc > >> transport. > >> > >> btrfs, cifs, f2fs and nfs all supply ->swap_deactivate() to undo the effects > >> of the activation. > > > > Right ... so my question really is, now that we're doing I/O through > > aops->direct_IO (or ->swap_rw), do those magic things need to be done? > > After all, open(O_DIRECT) doesn't do these same magic things. They're > > really there to allow the direct-to-BIO path to work, and you're removing > > that here. > > For zonefs, ->swap_activate() checks that the user is not trying to use a > sequential write only file for swap. Swap cannot work on these files as there > are no guarantees that the writes will be sequential. iomap_swapfile_activate() is used by ext4, XFS and zonefs. It checks there are no holes in the file, no shared extents, no inline extents, the swap info block device matches the block device the extent is mapped to (i.e. filesystems can have more than one bdev, swapfile only supports files on sb->s_bdev), etc. Also, I noticed, iomap_swapfile_add_extent() filters out extents that are smaller than PAGE_SIZE, and aligns larger extents to PAGE_SIZE. This allows ensures that when fs block size != PAGE_SIZE that only a single IO per page being swapped is required. i.e. the DIO path may change the "one page, one bio, one IO" behaviour that the current swapfile mapping guarantees. Cheers, Dave. -- Dave Chinner david@fromorbit.com