From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by kanga.kvack.org (Postfix) with ESMTP id 3DC248E001A for ; Wed, 23 Jan 2019 09:54:38 -0500 (EST) Received: by mail-ed1-f70.google.com with SMTP id b3so1056719edi.0 for ; Wed, 23 Jan 2019 06:54:38 -0800 (PST) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id fx12-v6si2763342ejb.302.2019.01.23.06.54.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 06:54:36 -0800 (PST) Date: Wed, 23 Jan 2019 15:54:34 +0100 From: Jan Kara Subject: Re: [LSF/MM TOPIC] Sharing file backed pages Message-ID: <20190123145434.GK13149@quack2.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Amir Goldstein Cc: lsf-pc@lists.linux-foundation.org, Al Viro , "Darrick J. Wong" , Dave Chinner , Jan Kara , Matthew Wilcox , Chris Mason , Miklos Szeredi , linux-fsdevel , Linux MM , Jerome Glisse On Wed 23-01-19 10:48:58, Amir Goldstein wrote: > In his session about "reflink" in LSF/MM 2016 [1], Darrick Wong brought > up the subject of sharing pages between cloned files and the general vibe > in room was that it could be done. > > In his talk about XFS subvolumes and snapshots [2], Dave Chinner said > that Matthew Willcox was "working on that problem". > > I have started working on a new overlayfs address space implementation > that could also benefit from being able to share pages even for filesystems > that do not support clones (for copy up anticipation state). > > To simplify the problem, we can start with sharing only uptodate clean > pages that map the same offset in respected files. While the same offset > requirement somewhat limits the use cases that benefit from shared file > pages, there is still a vast majority of use cases (i.e. clone full > image), where sharing pages of similar offset will bring a lot of > benefit. > > At first glance, this requires dropping the assumption that a for an > uptodate clean page, vmf->vma->vm_file->f_inode == page->mapping->host. > Is there really such an assumption in common vfs/mm code? and what will > it take to drop it? There definitely is such assumption. Take for example page reclaim as one such place that will be non-trivial to deal with. You need to remove the page from page cache of all inodes that contain it without having any file context whatsoever. So you will need to create some way for this page->page caches mapping to happen. Jerome in his talk at LSF/MM last year [1] actually nicely summarized what it would take to get rid of page->mapping dereferences. He even had some preliminary patches. To sum it up, it's a lot of intrusive work but in principle it is possible. [1] https://lwn.net/Articles/752564/ Honza -- Jan Kara SUSE Labs, CR