Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4267357pxb; Mon, 27 Sep 2021 13:03:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzA7AEuV9qPszH7G5NfNyiofP9MEEn595yEqSb/aqy5GeBKuIG5N/e3NnzZrTSuzrG9P/po X-Received: by 2002:a17:90a:8009:: with SMTP id b9mr970385pjn.15.1632773028375; Mon, 27 Sep 2021 13:03:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632773028; cv=none; d=google.com; s=arc-20160816; b=U4rCtzu/vyB5uwvXYywwPVkzd9qJASjU9un6po6zLx3z4CcAczYc0uIRZIRTOl4qXd 77ONr1XjdWlrenB0nXWPVgegGO6D8cJkPPe1gQfEDUCkGOnzDCfphXsrEIRF6h5Ryhtl yQrnU7rINUTrJRK2vFw6LAZr+Bl1JNi5F81JrfEKyw6Lek0rBo9lwRSN0JINoP9g1gWW PJ7ToNQbJM5JA9seieeC3ft4n0NcM3ccfjHrf/gfsVNSztSZwniYUUJN6n6rLx9tMKJp LvzK/LXjzU49XKIZqI3TWpMuAZivgUKohSBj8fwt+zYEXJ8byiKgZBjTDNbMpMdU8ZP/ MnXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature:dkim-signature; bh=OWyy087kUcLdlyc/fMUCTYpqi5qxNMTXwsGsPPvHgDU=; b=anALcmT0iSYQLxFFqsFmdtTcNe6FWrGOxHg2tx0lzho1lpRViyKluMom4/e/h+Tavk kZBqJj2TZcW1ewwtJjs8wsDwsSeeXlb5D7Qbrj5jmKkHkMG3OVeEzTKoxRaZNF1mnsN5 3JSNsurOrFIpYStHUv1wctah1Q3zQqiAmuNIs30khTXI96hnfHD1qLAh2AEz8/nijkHM As+JblIE5ldg4wt7JDTgElRS2KYXT+mr7SwmG7MQUZrgReo2/5uwSefWzyX67unQo4Ta 5buyWYd2uaOlnQkTycPZI3Bey60OHGjwQVHldvovOlyp2keXVwUqwsftwR91Evn3HT7H peNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=kWibP7Iw; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; 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 x63si21887209pfx.150.2021.09.27.13.03.24; Mon, 27 Sep 2021 13:03:48 -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; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=kWibP7Iw; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; 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 S236681AbhI0UE7 (ORCPT + 99 others); Mon, 27 Sep 2021 16:04:59 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:39780 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230456AbhI0UE7 (ORCPT ); Mon, 27 Sep 2021 16:04:59 -0400 Received: from relay1.suse.de (relay1.suse.de [149.44.160.133]) by smtp-out2.suse.de (Postfix) with ESMTP id 373C31FF79; Mon, 27 Sep 2021 20:03:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1632772999; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OWyy087kUcLdlyc/fMUCTYpqi5qxNMTXwsGsPPvHgDU=; b=kWibP7IwsPtmLu1Z91YlWpRQCdwjku9jIL9nWyNAlXt52WM/cmjZMpdX6RVSEyAvmYspZe Hvz4gXkWKTESUOeX6ZYKqVRAuFqtd14BOB+lrP/PNqft0q9rAPKq/qYqQxSHouQU67RRQN LQe8zYMxT45IOXgaCreUieFpTycrqB4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1632772999; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OWyy087kUcLdlyc/fMUCTYpqi5qxNMTXwsGsPPvHgDU=; b=WWxu+gdW8UEBCsHxKgDJsEOiF45Qv/5XDpNAT1PmVspypr8yqEgnie2RREgD+1bm8EYsAl 7MO73hUAa6KcqnBw== Received: from ds.suse.cz (ds.suse.cz [10.100.12.205]) by relay1.suse.de (Postfix) with ESMTP id 04D5F25D3E; Mon, 27 Sep 2021 20:03:19 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 31B56DA799; Mon, 27 Sep 2021 22:03:02 +0200 (CEST) Date: Mon, 27 Sep 2021 22:03:02 +0200 From: David Sterba To: David Howells Cc: Matthew Wilcox , 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: <20210927200302.GH9286@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, David Howells , Matthew Wilcox , 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 References: <163250387273.2330363.13240781819520072222.stgit@warthog.procyon.org.uk> <163250396319.2330363.10564506508011638258.stgit@warthog.procyon.org.uk> <2396106.1632584202@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2396106.1632584202@warthog.procyon.org.uk> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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); > } > } > > > > 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. Yes we still need it for btrfs. Besides checking the conditions similar to what iomap_swapfile_activate does on the file itself, we need to exclude other operations potentially changing the mapping on the level of block groups. This is namely relocation, used to implement several other things like resize or balance. There's an exclusion at the beginning of btrfs_swap_activate. Right now I don't see how we could make sure that the swapfile requirements would be satisfied without it.