From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: direct_access, pinning and truncation Date: Sun, 19 Oct 2014 14:08:07 +0300 Message-ID: <54439B97.7020305@gmail.com> References: <20141008190523.GM5098@wil.cx> <20141010130805.GC25693@quack.suse.cz> <20141010142430.GR5098@wil.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: Matthew Wilcox , Jan Kara Return-path: Received: from mail-wg0-f49.google.com ([74.125.82.49]:48216 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbaJSLIL (ORCPT ); Sun, 19 Oct 2014 07:08:11 -0400 Received: by mail-wg0-f49.google.com with SMTP id x12so3570461wgg.8 for ; Sun, 19 Oct 2014 04:08:10 -0700 (PDT) In-Reply-To: <20141010142430.GR5098@wil.cx> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 10/10/2014 05:24 PM, Matthew Wilcox wrote: <> > > I'm assuming that we come up with *some* way to solve the missing struct > page problem. Whether it's restructuring splice, O_DIRECT and RDMA to do > without struct pages, That makes no sense to me, where will it end? You are doubling the size of the code to have two paths, and there will always be a subsystem you did not touch and is missing support. And why? page was already invented to do exactly what you want, track state of a PFN. > whether it's dynamically allocating struct pages, I have tried this. It does not work. The PFN <-> page mapping is directly calculated from the phisical/virtual addresses. Through the use of the section object. struct page is actually just a part of a bigger "section" object. You do not allocate an individual page-struct. You need to allocate a memory "section" > whether it's statically allocating struct pages, The best I came up with was "hotplug" allocation. It is rather static, but hot plugable. Please inspect my patches. This came out very simple, the minimum code possible that gives you all the above support, without need to change any of these subsystems, and plugs just nicely into all the other subsystems you have not mentioned. > whether it's coming up > with some other data structure that takes the place of struct page for > DAX ... Again. Why reinvent the wheel when the old one works perfectly and does everything you want, including the most important aspect. Not adding any new infrastructure, and/or modifying any code. So why even think about it? > doesn't matter for this part of the conversation. > I agree, this does not solve the reference problem, in this case DAX will need an new entry into the FS to communicate delayed free-block. But as Jan pointed out this is not against current FS structure. I think lots of current DAX problems and performance short comings can be solved very nicely if we assume we have struct-page for pmem. For example the use of the page-lock instead of the i_mutex we take today. Thanks Boaz