From: Dave Hansen <dave.hansen@intel.com>
To: Boaz Harrosh <boaz@plexistor.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Jens Axboe <axboe@fb.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-nvdimm@lists.01.org, Toshi Kani <toshi.kani@hp.com>,
linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/9] mm: Let sparse_{add,remove}_one_section receive a node_id
Date: Wed, 10 Sep 2014 11:28:21 -0700 [thread overview]
Message-ID: <54109845.3050309@intel.com> (raw)
In-Reply-To: <5410899C.3030501@plexistor.com>
On 09/10/2014 10:25 AM, Boaz Harrosh wrote:
> Yes the block_allocator of the pmem-FS always holds the final REF on this
> page, as long as there is valid data on this block. Even cross boots, the
> mount code re-initializes references. The only internal state that frees
> these blocks is truncate, which only then return these pages to the block
> allocator, all this is common practice in filesystems so the page-ref on
> these blocks only ever drops to zero after they loose all visibility. And
> yes the block allocator uses a special code to drop the count to zero
> not using put_page().
OK, so what happens when a page is truncated out of a file and this
"last" block reference is dropped while a get_user_pages() still has a
reference?
> On 09/10/2014 07:10 PM, Dave Hansen wrote:
>> Does the fs support mmap()?
>>
> No!
>
> Yes the FS supports mmap, but through the DAX patchset. Please see
> Matthew's DAX patchset how he implements mmap without using pages
> at all, direct PFN to virtual_addr. So these pages do not get exposed
> to the top of the FS.
>
> My FS uses his technics exactly only when it wants to spill over to
> slower device it will use these pages copy-less.
>From my perspective, DAX is complicated, but it is necessary because we
don't have a 'struct page'. You're saying that even if we pay the cost
of a 'struct page' for the memory, we still don't get the benefit of
having it like getting rid of this DAX stuff?
Also, about not having a zone for these pages. Do you intend to support
32-bit systems? If so, I believe you will require the kmap() family of
functions to map the pages in order to copy data in and out. kmap()
currently requires knowing the zone of the page.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-09-10 18:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1409173922-7484-1-git-send-email-ross.zwisler@linux.intel.com>
2014-09-09 15:37 ` [PATCH 0/9] pmem: Fixes and farther development (mm: add_persistent_memory) Boaz Harrosh
2014-09-09 15:45 ` [PATCH 5/9] mm: Let sparse_{add,remove}_one_section receive a node_id Boaz Harrosh
2014-09-09 18:36 ` Dave Hansen
2014-09-10 10:07 ` Boaz Harrosh
2014-09-10 16:10 ` Dave Hansen
2014-09-10 17:25 ` Boaz Harrosh
2014-09-10 18:28 ` Dave Hansen [this message]
2014-09-11 8:39 ` Boaz Harrosh
2014-09-11 17:07 ` Dave Hansen
2014-09-14 9:36 ` Boaz Harrosh
2014-09-09 15:47 ` [PATCH 6/9] mm: New add_persistent_memory/remove_persistent_memory Boaz Harrosh
2014-09-09 15:48 ` [PATCH 7/9] pmem: Add support for page structs Boaz Harrosh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54109845.3050309@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=boaz@plexistor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=matthew.r.wilcox@intel.com \
--cc=ross.zwisler@linux.intel.com \
--cc=toshi.kani@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).