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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 6DFF2C282C0 for ; Wed, 23 Jan 2019 15:26:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 42F4721850 for ; Wed, 23 Jan 2019 15:26:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726109AbfAWP0T (ORCPT ); Wed, 23 Jan 2019 10:26:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43096 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfAWP0T (ORCPT ); Wed, 23 Jan 2019 10:26:19 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4A8C80F7C; Wed, 23 Jan 2019 15:26:18 +0000 (UTC) Received: from redhat.com (ovpn-124-254.rdu2.redhat.com [10.10.124.254]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C60C85EDF7; Wed, 23 Jan 2019 15:26:16 +0000 (UTC) Date: Wed, 23 Jan 2019 10:26:14 -0500 From: Jerome Glisse To: Jan Kara Cc: Amir Goldstein , lsf-pc@lists.linux-foundation.org, Al Viro , "Darrick J. Wong" , Dave Chinner , Matthew Wilcox , Chris Mason , Miklos Szeredi , linux-fsdevel , Linux MM Subject: Re: [LSF/MM TOPIC] Sharing file backed pages Message-ID: <20190123152613.GB3097@redhat.com> References: <20190123145434.GK13149@quack2.suse.cz> <20190123151228.GA3097@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190123151228.GA3097@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 23 Jan 2019 15:26:19 +0000 (UTC) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Jan 23, 2019 at 10:12:29AM -0500, Jerome Glisse wrote: > On Wed, Jan 23, 2019 at 03:54:34PM +0100, Jan Kara wrote: > > 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/ > > > > I intend to post a v2 of my patchset doing that sometime soon. For > various reasons this had been push to the bottom of my todo list since > last year. It is now almost at the top and it will stay at the top. > So i will be resuming work on that. > > I wanted to propose this topic again as a joint session with mm so > here is my proposal: > > > I would like to discuss the removal of page mapping field dependency > in most kernel code path so the we can overload that field for generic > page write protection (KSM) for file back pages. The whole idea behind > this is that we almost always have the mapping a page belongs to within > the call stack for any function that operate on a file or on a vma do > have it: > - syscall/kernel on a file (file -> inode -> mapping) > - syscall/kernel on virtual address (vma -> file -> mapping) > - write back for a given mapping > > Note that the plan is not to free up the mapping field in struct page > but to reduce the number of place that needs the mapping corresponding > to a page to as few places as possible. The few exceptions are: > - page reclaim > - memory compaction > - set_page_dirty() on GUPed (get_user_pages*()) pages > > For page reclaim and memory compaction we do not care about mapping > exactly but about being able to unmap/migrate a page. So any over- > loading of mapping needs to keep providing helpers to handle those > cases. > > For set_page_dirty() on GUPed pages we can take a slow path if the > page has an overloaded mapping field. > > > Previous patchset: > https://lore.kernel.org/lkml/20180404191831.5378-1-jglisse@redhat.com/ Stupid me forget to say what i want to talk about during LSF/MM session: - very quick overlook of the patchset and then taking questions on it - gather people feeling/opinion (does it looks good ?) - merging strategy for which i have some thought and would like to gather feedback on them I expect to post a v2 long before LSF/MM probably in February so people will have sometime to look at it. A warning it is almost entirely all done with coccinelle as it is almost only mechanical changes. Cheers, Jérôme