From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCE05C17440 for ; Tue, 12 Nov 2019 13:30:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9E0921783 for ; Tue, 12 Nov 2019 13:30:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9E0921783 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 223B96B0006; Tue, 12 Nov 2019 08:30:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D4726B0007; Tue, 12 Nov 2019 08:30:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EA6E6B0008; Tue, 12 Nov 2019 08:30:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id E9AFF6B0006 for ; Tue, 12 Nov 2019 08:30:58 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id AB4188249980 for ; Tue, 12 Nov 2019 13:30:58 +0000 (UTC) X-FDA: 76147710996.07.songs14_42ac642212844 X-HE-Tag: songs14_42ac642212844 X-Filterd-Recvd-Size: 3198 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Nov 2019 13:30:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 44A94AEEE; Tue, 12 Nov 2019 13:30:56 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 462B11E4AD2; Tue, 12 Nov 2019 14:30:55 +0100 (CET) Date: Tue, 12 Nov 2019 14:30:55 +0100 From: Jan Kara To: Christoph Hellwig Cc: ira.weiny@intel.com, Alexander Viro , Andrew Morton , Chris Mason , Josef Bacik , David Sterba , Jaegeuk Kim , Chao Yu , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-nfs@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Jan Kara Subject: Re: [PATCH 2/2] fs: Move swap_[de]activate to file_operations Message-ID: <20191112133055.GI1241@quack2.suse.cz> References: <20191112003452.4756-1-ira.weiny@intel.com> <20191112003452.4756-3-ira.weiny@intel.com> <20191112065507.GA15915@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191112065507.GA15915@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 11-11-19 22:55:07, Christoph Hellwig wrote: > On Mon, Nov 11, 2019 at 04:34:52PM -0800, ira.weiny@intel.com wrote: > > From: Ira Weiny > > > > swap_activate() and swap_deactivate() have nothing to do with > > address spaces. We want to eventually make the address space operations > > dynamic to switch inode flags on the fly. So to simplify this code as > > well as properly track these operations we move these functions to the > > file_operations vector. > > What is the point? If we switch aops for DAX vs not we might as well > switch file operations as well, as they pretty much are entirely > different. Ira is trying to make switching of inodes between DAX and non-DAX mode work. Currently, we have different address_space_operations for DAX vs non-DAX and that makes sense because operation for address_space is vastly different for DAX compared to page cache. But switching of aops is difficult to do reliably so I've suggested to move functions that don't make too much sense in aops out to simplify the picture. Currently file_operations are the same (both on XFS and ext4) for DAX and non-DAX case so we don't need to switch them. And although I agree that for some operations split may make sense, I think most of the operations would be actually the same for DAX vs non-DAX case so I don't see a point in separating file_operations for DAX vs non-DAX case. Honza -- Jan Kara SUSE Labs, CR