Re: direct_access, pinning and truncation

[Boaz Harrosh <openosd@gmail.com>]

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