2019-05-29 22:18:02 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2015-02-17 07:58:56 +08:00
|
|
|
/*
|
|
|
|
* fs/dax.c - Direct Access filesystem code
|
|
|
|
* Copyright (c) 2013-2014 Intel Corporation
|
|
|
|
* Author: Matthew Wilcox <matthew.r.wilcox@intel.com>
|
|
|
|
* Author: Ross Zwisler <ross.zwisler@linux.intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/atomic.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/buffer_head.h>
|
2015-09-10 00:29:40 +08:00
|
|
|
#include <linux/dax.h>
|
2015-02-17 07:58:56 +08:00
|
|
|
#include <linux/fs.h>
|
2015-02-17 07:59:02 +08:00
|
|
|
#include <linux/highmem.h>
|
|
|
|
#include <linux/memcontrol.h>
|
|
|
|
#include <linux/mm.h>
|
2015-02-17 07:58:56 +08:00
|
|
|
#include <linux/mutex.h>
|
2016-01-23 07:10:47 +08:00
|
|
|
#include <linux/pagevec.h>
|
2015-02-17 07:58:59 +08:00
|
|
|
#include <linux/sched.h>
|
2017-02-04 06:47:37 +08:00
|
|
|
#include <linux/sched/signal.h>
|
2015-02-17 07:58:56 +08:00
|
|
|
#include <linux/uio.h>
|
2015-02-17 07:59:02 +08:00
|
|
|
#include <linux/vmstat.h>
|
2016-01-16 08:56:14 +08:00
|
|
|
#include <linux/pfn_t.h>
|
2016-01-16 08:55:53 +08:00
|
|
|
#include <linux/sizes.h>
|
2016-12-15 07:07:53 +08:00
|
|
|
#include <linux/mmu_notifier.h>
|
2016-09-19 09:24:49 +08:00
|
|
|
#include <linux/iomap.h>
|
2019-03-09 20:07:21 +08:00
|
|
|
#include <asm/pgalloc.h>
|
2015-02-17 07:58:56 +08:00
|
|
|
|
2017-02-23 07:39:50 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/fs_dax.h>
|
|
|
|
|
2018-03-28 23:48:03 +08:00
|
|
|
static inline unsigned int pe_order(enum page_entry_size pe_size)
|
|
|
|
{
|
|
|
|
if (pe_size == PE_SIZE_PTE)
|
|
|
|
return PAGE_SHIFT - PAGE_SHIFT;
|
|
|
|
if (pe_size == PE_SIZE_PMD)
|
|
|
|
return PMD_SHIFT - PAGE_SHIFT;
|
|
|
|
if (pe_size == PE_SIZE_PUD)
|
|
|
|
return PUD_SHIFT - PAGE_SHIFT;
|
|
|
|
return ~0;
|
|
|
|
}
|
|
|
|
|
2016-05-13 00:29:18 +08:00
|
|
|
/* We choose 4096 entries - same as per-zone page wait tables */
|
|
|
|
#define DAX_WAIT_TABLE_BITS 12
|
|
|
|
#define DAX_WAIT_TABLE_ENTRIES (1 << DAX_WAIT_TABLE_BITS)
|
|
|
|
|
2017-09-07 07:18:58 +08:00
|
|
|
/* The 'colour' (ie low bits) within a PMD of a page offset. */
|
|
|
|
#define PG_PMD_COLOUR ((PMD_SIZE >> PAGE_SHIFT) - 1)
|
2018-02-01 08:17:36 +08:00
|
|
|
#define PG_PMD_NR (PMD_SIZE >> PAGE_SHIFT)
|
2017-09-07 07:18:58 +08:00
|
|
|
|
2018-03-28 23:48:03 +08:00
|
|
|
/* The order of a PMD entry */
|
|
|
|
#define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
|
|
|
|
|
2016-11-08 08:31:44 +08:00
|
|
|
static wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
|
2016-05-13 00:29:18 +08:00
|
|
|
|
|
|
|
static int __init init_dax_wait_table(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < DAX_WAIT_TABLE_ENTRIES; i++)
|
|
|
|
init_waitqueue_head(wait_table + i);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
fs_initcall(init_dax_wait_table);
|
|
|
|
|
2017-09-07 07:18:51 +08:00
|
|
|
/*
|
2017-11-04 01:30:42 +08:00
|
|
|
* DAX pagecache entries use XArray value entries so they can't be mistaken
|
|
|
|
* for pages. We use one bit for locking, one bit for the entry size (PMD)
|
|
|
|
* and two more to tell us if the entry is a zero page or an empty entry that
|
|
|
|
* is just used for locking. In total four special bits.
|
2017-09-07 07:18:51 +08:00
|
|
|
*
|
|
|
|
* If the PMD bit isn't set the entry has size PAGE_SIZE, and if the ZERO_PAGE
|
|
|
|
* and EMPTY bits aren't set the entry is a normal DAX entry with a filesystem
|
|
|
|
* block allocation.
|
|
|
|
*/
|
2017-11-04 01:30:42 +08:00
|
|
|
#define DAX_SHIFT (4)
|
|
|
|
#define DAX_LOCKED (1UL << 0)
|
|
|
|
#define DAX_PMD (1UL << 1)
|
|
|
|
#define DAX_ZERO_PAGE (1UL << 2)
|
|
|
|
#define DAX_EMPTY (1UL << 3)
|
2017-09-07 07:18:51 +08:00
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
static unsigned long dax_to_pfn(void *entry)
|
2017-09-07 07:18:51 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
return xa_to_value(entry) >> DAX_SHIFT;
|
2017-09-07 07:18:51 +08:00
|
|
|
}
|
|
|
|
|
2018-06-12 21:46:30 +08:00
|
|
|
static void *dax_make_entry(pfn_t pfn, unsigned long flags)
|
|
|
|
{
|
|
|
|
return xa_mk_value(flags | (pfn_t_to_pfn(pfn) << DAX_SHIFT));
|
|
|
|
}
|
|
|
|
|
2018-03-28 23:48:03 +08:00
|
|
|
static bool dax_is_locked(void *entry)
|
|
|
|
{
|
|
|
|
return xa_to_value(entry) & DAX_LOCKED;
|
|
|
|
}
|
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
static unsigned int dax_entry_order(void *entry)
|
2017-09-07 07:18:51 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
if (xa_to_value(entry) & DAX_PMD)
|
2018-03-28 23:48:03 +08:00
|
|
|
return PMD_ORDER;
|
2017-09-07 07:18:51 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-11-17 04:07:31 +08:00
|
|
|
static unsigned long dax_is_pmd_entry(void *entry)
|
2016-01-29 12:25:31 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
return xa_to_value(entry) & DAX_PMD;
|
2016-01-29 12:25:31 +08:00
|
|
|
}
|
|
|
|
|
2018-11-17 04:07:31 +08:00
|
|
|
static bool dax_is_pte_entry(void *entry)
|
2015-02-17 07:58:56 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
return !(xa_to_value(entry) & DAX_PMD);
|
2015-02-17 07:58:56 +08:00
|
|
|
}
|
|
|
|
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
static int dax_is_zero_entry(void *entry)
|
2015-02-17 07:58:56 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
return xa_to_value(entry) & DAX_ZERO_PAGE;
|
2015-02-17 07:58:56 +08:00
|
|
|
}
|
|
|
|
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
static int dax_is_empty_entry(void *entry)
|
2016-01-16 08:55:59 +08:00
|
|
|
{
|
2017-11-04 01:30:42 +08:00
|
|
|
return xa_to_value(entry) & DAX_EMPTY;
|
2016-01-16 08:55:59 +08:00
|
|
|
}
|
|
|
|
|
2019-07-04 11:21:25 +08:00
|
|
|
/*
|
|
|
|
* true if the entry that was found is of a smaller order than the entry
|
|
|
|
* we were looking for
|
|
|
|
*/
|
|
|
|
static bool dax_is_conflict(void *entry)
|
|
|
|
{
|
|
|
|
return entry == XA_RETRY_ENTRY;
|
|
|
|
}
|
|
|
|
|
2016-05-13 00:29:18 +08:00
|
|
|
/*
|
2018-03-28 01:39:38 +08:00
|
|
|
* DAX page cache entry locking
|
2016-05-13 00:29:18 +08:00
|
|
|
*/
|
|
|
|
struct exceptional_entry_key {
|
2018-03-28 23:01:43 +08:00
|
|
|
struct xarray *xa;
|
2016-11-08 08:32:20 +08:00
|
|
|
pgoff_t entry_start;
|
2016-05-13 00:29:18 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct wait_exceptional_entry_queue {
|
2017-06-20 18:06:13 +08:00
|
|
|
wait_queue_entry_t wait;
|
2016-05-13 00:29:18 +08:00
|
|
|
struct exceptional_entry_key key;
|
|
|
|
};
|
|
|
|
|
2021-04-29 03:03:12 +08:00
|
|
|
/**
|
|
|
|
* enum dax_wake_mode: waitqueue wakeup behaviour
|
|
|
|
* @WAKE_ALL: wake all waiters in the waitqueue
|
|
|
|
* @WAKE_NEXT: wake only the first waiter in the waitqueue
|
|
|
|
*/
|
|
|
|
enum dax_wake_mode {
|
|
|
|
WAKE_ALL,
|
|
|
|
WAKE_NEXT,
|
|
|
|
};
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
static wait_queue_head_t *dax_entry_waitqueue(struct xa_state *xas,
|
|
|
|
void *entry, struct exceptional_entry_key *key)
|
2016-11-08 08:32:20 +08:00
|
|
|
{
|
|
|
|
unsigned long hash;
|
2018-03-30 10:58:27 +08:00
|
|
|
unsigned long index = xas->xa_index;
|
2016-11-08 08:32:20 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If 'entry' is a PMD, align the 'index' that we use for the wait
|
|
|
|
* queue to the start of that PMD. This ensures that all offsets in
|
|
|
|
* the range covered by the PMD map to the same bit lock.
|
|
|
|
*/
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
if (dax_is_pmd_entry(entry))
|
2017-09-07 07:18:58 +08:00
|
|
|
index &= ~PG_PMD_COLOUR;
|
2018-03-30 10:58:27 +08:00
|
|
|
key->xa = xas->xa;
|
2016-11-08 08:32:20 +08:00
|
|
|
key->entry_start = index;
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
hash = hash_long((unsigned long)xas->xa ^ index, DAX_WAIT_TABLE_BITS);
|
2016-11-08 08:32:20 +08:00
|
|
|
return wait_table + hash;
|
|
|
|
}
|
|
|
|
|
2018-03-28 23:01:43 +08:00
|
|
|
static int wake_exceptional_entry_func(wait_queue_entry_t *wait,
|
|
|
|
unsigned int mode, int sync, void *keyp)
|
2016-05-13 00:29:18 +08:00
|
|
|
{
|
|
|
|
struct exceptional_entry_key *key = keyp;
|
|
|
|
struct wait_exceptional_entry_queue *ewait =
|
|
|
|
container_of(wait, struct wait_exceptional_entry_queue, wait);
|
|
|
|
|
2018-03-28 23:01:43 +08:00
|
|
|
if (key->xa != ewait->key.xa ||
|
2016-11-08 08:32:20 +08:00
|
|
|
key->entry_start != ewait->key.entry_start)
|
2016-05-13 00:29:18 +08:00
|
|
|
return 0;
|
|
|
|
return autoremove_wake_function(wait, mode, sync, NULL);
|
|
|
|
}
|
|
|
|
|
2017-09-07 07:18:39 +08:00
|
|
|
/*
|
2018-04-11 07:36:56 +08:00
|
|
|
* @entry may no longer be the entry at the index in the mapping.
|
|
|
|
* The important information it's conveying is whether the entry at
|
|
|
|
* this index used to be a PMD entry.
|
2017-09-07 07:18:39 +08:00
|
|
|
*/
|
2021-04-29 03:03:12 +08:00
|
|
|
static void dax_wake_entry(struct xa_state *xas, void *entry,
|
|
|
|
enum dax_wake_mode mode)
|
2017-09-07 07:18:39 +08:00
|
|
|
{
|
|
|
|
struct exceptional_entry_key key;
|
|
|
|
wait_queue_head_t *wq;
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
wq = dax_entry_waitqueue(xas, entry, &key);
|
2017-09-07 07:18:39 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Checking for locked entry and prepare_to_wait_exclusive() happens
|
2018-04-11 07:36:56 +08:00
|
|
|
* under the i_pages lock, ditto for entry handling in our callers.
|
2017-09-07 07:18:39 +08:00
|
|
|
* So at this point all tasks that could have seen our entry locked
|
|
|
|
* must be in the waitqueue and the following check will see them.
|
|
|
|
*/
|
|
|
|
if (waitqueue_active(wq))
|
2021-04-29 03:03:12 +08:00
|
|
|
__wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1, &key);
|
2017-09-07 07:18:39 +08:00
|
|
|
}
|
|
|
|
|
2018-03-28 23:48:03 +08:00
|
|
|
/*
|
|
|
|
* Look up entry in page cache, wait for it to become unlocked if it
|
|
|
|
* is a DAX entry and return it. The caller must subsequently call
|
|
|
|
* put_unlocked_entry() if it did not lock the entry or dax_unlock_entry()
|
2019-07-04 11:21:25 +08:00
|
|
|
* if it did. The entry returned may have a larger order than @order.
|
|
|
|
* If @order is larger than the order of the entry found in i_pages, this
|
|
|
|
* function returns a dax_is_conflict entry.
|
2018-03-28 23:48:03 +08:00
|
|
|
*
|
|
|
|
* Must be called with the i_pages lock held.
|
|
|
|
*/
|
2019-07-04 11:21:25 +08:00
|
|
|
static void *get_unlocked_entry(struct xa_state *xas, unsigned int order)
|
2018-03-28 23:48:03 +08:00
|
|
|
{
|
|
|
|
void *entry;
|
|
|
|
struct wait_exceptional_entry_queue ewait;
|
|
|
|
wait_queue_head_t *wq;
|
|
|
|
|
|
|
|
init_wait(&ewait.wait);
|
|
|
|
ewait.wait.func = wake_exceptional_entry_func;
|
|
|
|
|
|
|
|
for (;;) {
|
2018-11-17 04:19:13 +08:00
|
|
|
entry = xas_find_conflict(xas);
|
2019-10-22 00:29:20 +08:00
|
|
|
if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
|
|
|
|
return entry;
|
2019-07-04 11:21:25 +08:00
|
|
|
if (dax_entry_order(entry) < order)
|
|
|
|
return XA_RETRY_ENTRY;
|
2019-10-22 00:29:20 +08:00
|
|
|
if (!dax_is_locked(entry))
|
2018-03-28 23:48:03 +08:00
|
|
|
return entry;
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
wq = dax_entry_waitqueue(xas, entry, &ewait.key);
|
2018-03-28 23:48:03 +08:00
|
|
|
prepare_to_wait_exclusive(wq, &ewait.wait,
|
|
|
|
TASK_UNINTERRUPTIBLE);
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
xas_reset(xas);
|
|
|
|
schedule();
|
|
|
|
finish_wait(wq, &ewait.wait);
|
|
|
|
xas_lock_irq(xas);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-28 05:16:34 +08:00
|
|
|
/*
|
|
|
|
* The only thing keeping the address space around is the i_pages lock
|
|
|
|
* (it's cycled in clear_inode() after removing the entries from i_pages)
|
|
|
|
* After we call xas_unlock_irq(), we cannot touch xas->xa.
|
|
|
|
*/
|
|
|
|
static void wait_entry_unlocked(struct xa_state *xas, void *entry)
|
|
|
|
{
|
|
|
|
struct wait_exceptional_entry_queue ewait;
|
|
|
|
wait_queue_head_t *wq;
|
|
|
|
|
|
|
|
init_wait(&ewait.wait);
|
|
|
|
ewait.wait.func = wake_exceptional_entry_func;
|
|
|
|
|
|
|
|
wq = dax_entry_waitqueue(xas, entry, &ewait.key);
|
2018-12-22 03:35:53 +08:00
|
|
|
/*
|
|
|
|
* Unlike get_unlocked_entry() there is no guarantee that this
|
|
|
|
* path ever successfully retrieves an unlocked entry before an
|
|
|
|
* inode dies. Perform a non-exclusive wait in case this path
|
|
|
|
* never successfully performs its own wake up.
|
|
|
|
*/
|
|
|
|
prepare_to_wait(wq, &ewait.wait, TASK_UNINTERRUPTIBLE);
|
2018-11-28 05:16:34 +08:00
|
|
|
xas_unlock_irq(xas);
|
|
|
|
schedule();
|
|
|
|
finish_wait(wq, &ewait.wait);
|
|
|
|
}
|
|
|
|
|
2021-04-29 03:03:13 +08:00
|
|
|
static void put_unlocked_entry(struct xa_state *xas, void *entry,
|
|
|
|
enum dax_wake_mode mode)
|
2018-03-28 23:48:03 +08:00
|
|
|
{
|
2019-07-29 19:57:49 +08:00
|
|
|
if (entry && !dax_is_conflict(entry))
|
2021-04-29 03:03:13 +08:00
|
|
|
dax_wake_entry(xas, entry, mode);
|
2018-03-28 23:48:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We used the xa_state to get the entry, but then we locked the entry and
|
|
|
|
* dropped the xa_lock, so we know the xa_state is stale and must be reset
|
|
|
|
* before use.
|
|
|
|
*/
|
|
|
|
static void dax_unlock_entry(struct xa_state *xas, void *entry)
|
|
|
|
{
|
|
|
|
void *old;
|
|
|
|
|
2018-11-10 09:09:37 +08:00
|
|
|
BUG_ON(dax_is_locked(entry));
|
2018-03-28 23:48:03 +08:00
|
|
|
xas_reset(xas);
|
|
|
|
xas_lock_irq(xas);
|
|
|
|
old = xas_store(xas, entry);
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
BUG_ON(!dax_is_locked(old));
|
2021-04-29 03:03:12 +08:00
|
|
|
dax_wake_entry(xas, entry, WAKE_NEXT);
|
2018-03-28 23:48:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return: The entry stored at this location before it was locked.
|
|
|
|
*/
|
|
|
|
static void *dax_lock_entry(struct xa_state *xas, void *entry)
|
|
|
|
{
|
|
|
|
unsigned long v = xa_to_value(entry);
|
|
|
|
return xas_store(xas, xa_mk_value(v | DAX_LOCKED));
|
|
|
|
}
|
|
|
|
|
2017-12-23 14:02:48 +08:00
|
|
|
static unsigned long dax_entry_size(void *entry)
|
|
|
|
{
|
|
|
|
if (dax_is_zero_entry(entry))
|
|
|
|
return 0;
|
|
|
|
else if (dax_is_empty_entry(entry))
|
|
|
|
return 0;
|
|
|
|
else if (dax_is_pmd_entry(entry))
|
|
|
|
return PMD_SIZE;
|
|
|
|
else
|
|
|
|
return PAGE_SIZE;
|
|
|
|
}
|
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
static unsigned long dax_end_pfn(void *entry)
|
2017-12-23 14:02:48 +08:00
|
|
|
{
|
2018-03-28 01:39:38 +08:00
|
|
|
return dax_to_pfn(entry) + dax_entry_size(entry) / PAGE_SIZE;
|
2017-12-23 14:02:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Iterate through all mapped pfns represented by an entry, i.e. skip
|
|
|
|
* 'empty' and 'zero' entries.
|
|
|
|
*/
|
|
|
|
#define for_each_mapped_pfn(entry, pfn) \
|
2018-03-28 01:39:38 +08:00
|
|
|
for (pfn = dax_to_pfn(entry); \
|
|
|
|
pfn < dax_end_pfn(entry); pfn++)
|
2017-12-23 14:02:48 +08:00
|
|
|
|
2018-07-14 12:49:50 +08:00
|
|
|
/*
|
|
|
|
* TODO: for reflink+dax we need a way to associate a single page with
|
|
|
|
* multiple address_space instances at different linear_page_index()
|
|
|
|
* offsets.
|
|
|
|
*/
|
|
|
|
static void dax_associate_entry(void *entry, struct address_space *mapping,
|
|
|
|
struct vm_area_struct *vma, unsigned long address)
|
2017-12-23 14:02:48 +08:00
|
|
|
{
|
2018-07-14 12:49:50 +08:00
|
|
|
unsigned long size = dax_entry_size(entry), pfn, index;
|
|
|
|
int i = 0;
|
2017-12-23 14:02:48 +08:00
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_FS_DAX_LIMITED))
|
|
|
|
return;
|
|
|
|
|
2018-07-14 12:49:50 +08:00
|
|
|
index = linear_page_index(vma, address & ~(size - 1));
|
2017-12-23 14:02:48 +08:00
|
|
|
for_each_mapped_pfn(entry, pfn) {
|
|
|
|
struct page *page = pfn_to_page(pfn);
|
|
|
|
|
|
|
|
WARN_ON_ONCE(page->mapping);
|
|
|
|
page->mapping = mapping;
|
2018-07-14 12:49:50 +08:00
|
|
|
page->index = index + i++;
|
2017-12-23 14:02:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dax_disassociate_entry(void *entry, struct address_space *mapping,
|
|
|
|
bool trunc)
|
|
|
|
{
|
|
|
|
unsigned long pfn;
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_FS_DAX_LIMITED))
|
|
|
|
return;
|
|
|
|
|
|
|
|
for_each_mapped_pfn(entry, pfn) {
|
|
|
|
struct page *page = pfn_to_page(pfn);
|
|
|
|
|
|
|
|
WARN_ON_ONCE(trunc && page_ref_count(page) > 1);
|
|
|
|
WARN_ON_ONCE(page->mapping && page->mapping != mapping);
|
|
|
|
page->mapping = NULL;
|
2018-07-14 12:49:50 +08:00
|
|
|
page->index = 0;
|
2017-12-23 14:02:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
static struct page *dax_busy_page(void *entry)
|
|
|
|
{
|
|
|
|
unsigned long pfn;
|
|
|
|
|
|
|
|
for_each_mapped_pfn(entry, pfn) {
|
|
|
|
struct page *page = pfn_to_page(pfn);
|
|
|
|
|
|
|
|
if (page_ref_count(page) > 1)
|
|
|
|
return page;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-11-17 03:37:06 +08:00
|
|
|
/*
|
2022-01-27 20:40:53 +08:00
|
|
|
* dax_lock_page - Lock the DAX entry corresponding to a page
|
2018-11-17 03:37:06 +08:00
|
|
|
* @page: The page whose entry we want to lock
|
|
|
|
*
|
|
|
|
* Context: Process context.
|
2018-12-01 00:05:06 +08:00
|
|
|
* Return: A cookie to pass to dax_unlock_page() or 0 if the entry could
|
|
|
|
* not be locked.
|
2018-11-17 03:37:06 +08:00
|
|
|
*/
|
2018-12-01 00:05:06 +08:00
|
|
|
dax_entry_t dax_lock_page(struct page *page)
|
2018-07-14 12:50:16 +08:00
|
|
|
{
|
2018-06-12 21:46:30 +08:00
|
|
|
XA_STATE(xas, NULL, 0);
|
|
|
|
void *entry;
|
2018-07-14 12:50:16 +08:00
|
|
|
|
2018-11-17 03:37:06 +08:00
|
|
|
/* Ensure page->mapping isn't freed while we look at it */
|
|
|
|
rcu_read_lock();
|
2018-07-14 12:50:16 +08:00
|
|
|
for (;;) {
|
2018-06-12 21:46:30 +08:00
|
|
|
struct address_space *mapping = READ_ONCE(page->mapping);
|
2018-07-14 12:50:16 +08:00
|
|
|
|
2018-12-01 00:05:06 +08:00
|
|
|
entry = NULL;
|
2018-11-28 05:16:33 +08:00
|
|
|
if (!mapping || !dax_mapping(mapping))
|
2018-11-17 03:37:06 +08:00
|
|
|
break;
|
2018-07-14 12:50:16 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the device-dax case there's no need to lock, a
|
|
|
|
* struct dev_pagemap pin is sufficient to keep the
|
|
|
|
* inode alive, and we assume we have dev_pagemap pin
|
|
|
|
* otherwise we would not have a valid pfn_to_page()
|
|
|
|
* translation.
|
|
|
|
*/
|
2018-12-01 00:05:06 +08:00
|
|
|
entry = (void *)~0UL;
|
2018-06-12 21:46:30 +08:00
|
|
|
if (S_ISCHR(mapping->host->i_mode))
|
2018-11-17 03:37:06 +08:00
|
|
|
break;
|
2018-07-14 12:50:16 +08:00
|
|
|
|
2018-06-12 21:46:30 +08:00
|
|
|
xas.xa = &mapping->i_pages;
|
|
|
|
xas_lock_irq(&xas);
|
2018-07-14 12:50:16 +08:00
|
|
|
if (mapping != page->mapping) {
|
2018-06-12 21:46:30 +08:00
|
|
|
xas_unlock_irq(&xas);
|
2018-07-14 12:50:16 +08:00
|
|
|
continue;
|
|
|
|
}
|
2018-06-12 21:46:30 +08:00
|
|
|
xas_set(&xas, page->index);
|
|
|
|
entry = xas_load(&xas);
|
|
|
|
if (dax_is_locked(entry)) {
|
2018-11-17 03:37:06 +08:00
|
|
|
rcu_read_unlock();
|
2018-11-28 05:16:34 +08:00
|
|
|
wait_entry_unlocked(&xas, entry);
|
2018-11-17 03:37:06 +08:00
|
|
|
rcu_read_lock();
|
2018-11-07 02:11:57 +08:00
|
|
|
continue;
|
2018-07-14 12:50:16 +08:00
|
|
|
}
|
2018-06-12 21:46:30 +08:00
|
|
|
dax_lock_entry(&xas, entry);
|
|
|
|
xas_unlock_irq(&xas);
|
2018-11-17 03:37:06 +08:00
|
|
|
break;
|
2018-07-14 12:50:16 +08:00
|
|
|
}
|
2018-11-17 03:37:06 +08:00
|
|
|
rcu_read_unlock();
|
2018-12-01 00:05:06 +08:00
|
|
|
return (dax_entry_t)entry;
|
2018-07-14 12:50:16 +08:00
|
|
|
}
|
|
|
|
|
2018-12-01 00:05:06 +08:00
|
|
|
void dax_unlock_page(struct page *page, dax_entry_t cookie)
|
2018-07-14 12:50:16 +08:00
|
|
|
{
|
|
|
|
struct address_space *mapping = page->mapping;
|
2018-06-12 21:46:30 +08:00
|
|
|
XA_STATE(xas, &mapping->i_pages, page->index);
|
2018-07-14 12:50:16 +08:00
|
|
|
|
2018-06-12 21:46:30 +08:00
|
|
|
if (S_ISCHR(mapping->host->i_mode))
|
2018-07-14 12:50:16 +08:00
|
|
|
return;
|
|
|
|
|
2018-12-01 00:05:06 +08:00
|
|
|
dax_unlock_entry(&xas, (void *)cookie);
|
2018-07-14 12:50:16 +08:00
|
|
|
}
|
|
|
|
|
2016-05-13 00:29:18 +08:00
|
|
|
/*
|
2018-03-28 01:39:38 +08:00
|
|
|
* Find page cache entry at given index. If it is a DAX entry, return it
|
|
|
|
* with the entry locked. If the page cache doesn't contain an entry at
|
|
|
|
* that index, add a locked empty entry.
|
2016-05-13 00:29:18 +08:00
|
|
|
*
|
2017-11-04 01:30:42 +08:00
|
|
|
* When requesting an entry with size DAX_PMD, grab_mapping_entry() will
|
2018-03-30 10:58:27 +08:00
|
|
|
* either return that locked entry or will return VM_FAULT_FALLBACK.
|
|
|
|
* This will happen if there are any PTE entries within the PMD range
|
|
|
|
* that we are requesting.
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
*
|
2018-03-30 10:58:27 +08:00
|
|
|
* We always favor PTE entries over PMD entries. There isn't a flow where we
|
|
|
|
* evict PTE entries in order to 'upgrade' them to a PMD entry. A PMD
|
|
|
|
* insertion will fail if it finds any PTE entries already in the tree, and a
|
|
|
|
* PTE insertion will cause an existing PMD entry to be unmapped and
|
|
|
|
* downgraded to PTE entries. This happens for both PMD zero pages as
|
|
|
|
* well as PMD empty entries.
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
*
|
2018-03-30 10:58:27 +08:00
|
|
|
* The exception to this downgrade path is for PMD entries that have
|
|
|
|
* real storage backing them. We will leave these real PMD entries in
|
|
|
|
* the tree, and PTE writes will simply dirty the entire PMD entry.
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
*
|
2016-05-13 00:29:18 +08:00
|
|
|
* Note: Unlike filemap_fault() we don't honor FAULT_FLAG_RETRY flags. For
|
|
|
|
* persistent memory the benefit is doubtful. We can add that later if we can
|
|
|
|
* show it helps.
|
2018-03-30 10:58:27 +08:00
|
|
|
*
|
|
|
|
* On error, this function does not return an ERR_PTR. Instead it returns
|
|
|
|
* a VM_FAULT code, encoded as an xarray internal entry. The ERR_PTR values
|
|
|
|
* overlap with xarray value entries.
|
2016-05-13 00:29:18 +08:00
|
|
|
*/
|
2018-03-30 10:58:27 +08:00
|
|
|
static void *grab_mapping_entry(struct xa_state *xas,
|
2019-07-04 11:21:25 +08:00
|
|
|
struct address_space *mapping, unsigned int order)
|
2016-05-13 00:29:18 +08:00
|
|
|
{
|
2018-03-30 10:58:27 +08:00
|
|
|
unsigned long index = xas->xa_index;
|
2021-06-29 10:35:04 +08:00
|
|
|
bool pmd_downgrade; /* splitting PMD entry into PTE entries? */
|
2018-03-30 10:58:27 +08:00
|
|
|
void *entry;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
retry:
|
2021-06-29 10:35:04 +08:00
|
|
|
pmd_downgrade = false;
|
2018-03-30 10:58:27 +08:00
|
|
|
xas_lock_irq(xas);
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = get_unlocked_entry(xas, order);
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
if (entry) {
|
2019-07-04 11:21:25 +08:00
|
|
|
if (dax_is_conflict(entry))
|
|
|
|
goto fallback;
|
2018-11-17 04:19:13 +08:00
|
|
|
if (!xa_is_value(entry)) {
|
2020-07-29 11:44:36 +08:00
|
|
|
xas_set_err(xas, -EIO);
|
2018-03-30 10:58:27 +08:00
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
2019-07-04 11:21:25 +08:00
|
|
|
if (order == 0) {
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
if (dax_is_pmd_entry(entry) &&
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
(dax_is_zero_entry(entry) ||
|
|
|
|
dax_is_empty_entry(entry))) {
|
|
|
|
pmd_downgrade = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
if (pmd_downgrade) {
|
|
|
|
/*
|
|
|
|
* Make sure 'entry' remains valid while we drop
|
|
|
|
* the i_pages lock.
|
|
|
|
*/
|
|
|
|
dax_lock_entry(xas, entry);
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Besides huge zero pages the only other thing that gets
|
|
|
|
* downgraded are empty entries which don't need to be
|
|
|
|
* unmapped.
|
|
|
|
*/
|
2018-03-30 10:58:27 +08:00
|
|
|
if (dax_is_zero_entry(entry)) {
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
unmap_mapping_pages(mapping,
|
|
|
|
xas->xa_index & ~PG_PMD_COLOUR,
|
|
|
|
PG_PMD_NR, false);
|
|
|
|
xas_reset(xas);
|
|
|
|
xas_lock_irq(xas);
|
2017-04-08 07:04:57 +08:00
|
|
|
}
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
dax_disassociate_entry(entry, mapping, false);
|
|
|
|
xas_store(xas, NULL); /* undo the PMD join */
|
2021-04-29 03:03:12 +08:00
|
|
|
dax_wake_entry(xas, entry, WAKE_ALL);
|
2021-05-05 09:32:51 +08:00
|
|
|
mapping->nrpages -= PG_PMD_NR;
|
2018-03-30 10:58:27 +08:00
|
|
|
entry = NULL;
|
|
|
|
xas_set(xas, index);
|
|
|
|
}
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
if (entry) {
|
|
|
|
dax_lock_entry(xas, entry);
|
|
|
|
} else {
|
2019-07-04 11:21:25 +08:00
|
|
|
unsigned long flags = DAX_EMPTY;
|
|
|
|
|
|
|
|
if (order > 0)
|
|
|
|
flags |= DAX_PMD;
|
|
|
|
entry = dax_make_entry(pfn_to_pfn_t(0), flags);
|
2018-03-30 10:58:27 +08:00
|
|
|
dax_lock_entry(xas, entry);
|
|
|
|
if (xas_error(xas))
|
|
|
|
goto out_unlock;
|
2021-05-05 09:32:51 +08:00
|
|
|
mapping->nrpages += 1UL << order;
|
2016-05-13 00:29:18 +08:00
|
|
|
}
|
2018-03-30 10:58:27 +08:00
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
if (xas_nomem(xas, mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM))
|
|
|
|
goto retry;
|
|
|
|
if (xas->xa_node == XA_ERROR(-ENOMEM))
|
|
|
|
return xa_mk_internal(VM_FAULT_OOM);
|
|
|
|
if (xas_error(xas))
|
|
|
|
return xa_mk_internal(VM_FAULT_SIGBUS);
|
2016-11-08 08:32:12 +08:00
|
|
|
return entry;
|
2018-03-30 10:58:27 +08:00
|
|
|
fallback:
|
|
|
|
xas_unlock_irq(xas);
|
|
|
|
return xa_mk_internal(VM_FAULT_FALLBACK);
|
2016-05-13 00:29:18 +08:00
|
|
|
}
|
|
|
|
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
/**
|
2020-03-04 03:58:21 +08:00
|
|
|
* dax_layout_busy_page_range - find first pinned page in @mapping
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
* @mapping: address space to scan for a page with ref count > 1
|
2020-03-04 03:58:21 +08:00
|
|
|
* @start: Starting offset. Page containing 'start' is included.
|
|
|
|
* @end: End offset. Page containing 'end' is included. If 'end' is LLONG_MAX,
|
|
|
|
* pages from 'start' till the end of file are included.
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
*
|
|
|
|
* DAX requires ZONE_DEVICE mapped pages. These pages are never
|
|
|
|
* 'onlined' to the page allocator so they are considered idle when
|
|
|
|
* page->count == 1. A filesystem uses this interface to determine if
|
|
|
|
* any page in the mapping is busy, i.e. for DMA, or other
|
|
|
|
* get_user_pages() usages.
|
|
|
|
*
|
|
|
|
* It is expected that the filesystem is holding locks to block the
|
|
|
|
* establishment of new mappings in this address_space. I.e. it expects
|
|
|
|
* to be able to run unmap_mapping_range() and subsequently not race
|
|
|
|
* mapping_mapped() becoming true.
|
|
|
|
*/
|
2020-03-04 03:58:21 +08:00
|
|
|
struct page *dax_layout_busy_page_range(struct address_space *mapping,
|
|
|
|
loff_t start, loff_t end)
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
{
|
2018-05-18 01:03:48 +08:00
|
|
|
void *entry;
|
|
|
|
unsigned int scanned = 0;
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
struct page *page = NULL;
|
2020-03-04 03:58:21 +08:00
|
|
|
pgoff_t start_idx = start >> PAGE_SHIFT;
|
|
|
|
pgoff_t end_idx;
|
|
|
|
XA_STATE(xas, &mapping->i_pages, start_idx);
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the 'limited' case get_user_pages() for dax is disabled.
|
|
|
|
*/
|
|
|
|
if (IS_ENABLED(CONFIG_FS_DAX_LIMITED))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (!dax_mapping(mapping) || !mapping_mapped(mapping))
|
|
|
|
return NULL;
|
|
|
|
|
2020-03-04 03:58:21 +08:00
|
|
|
/* If end == LLONG_MAX, all pages from start to till end of file */
|
|
|
|
if (end == LLONG_MAX)
|
|
|
|
end_idx = ULONG_MAX;
|
|
|
|
else
|
|
|
|
end_idx = end >> PAGE_SHIFT;
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
/*
|
|
|
|
* If we race get_user_pages_fast() here either we'll see the
|
2018-05-18 01:03:48 +08:00
|
|
|
* elevated page count in the iteration and wait, or
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
* get_user_pages_fast() will see that the page it took a reference
|
|
|
|
* against is no longer mapped in the page tables and bail to the
|
|
|
|
* get_user_pages() slow path. The slow path is protected by
|
|
|
|
* pte_lock() and pmd_lock(). New references are not taken without
|
2020-03-04 03:58:21 +08:00
|
|
|
* holding those locks, and unmap_mapping_pages() will not zero the
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
* pte or pmd without holding the respective lock, so we are
|
|
|
|
* guaranteed to either see new references or prevent new
|
|
|
|
* references from being established.
|
|
|
|
*/
|
2020-03-04 03:58:21 +08:00
|
|
|
unmap_mapping_pages(mapping, start_idx, end_idx - start_idx + 1, 0);
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
|
2018-05-18 01:03:48 +08:00
|
|
|
xas_lock_irq(&xas);
|
2020-03-04 03:58:21 +08:00
|
|
|
xas_for_each(&xas, entry, end_idx) {
|
2018-05-18 01:03:48 +08:00
|
|
|
if (WARN_ON_ONCE(!xa_is_value(entry)))
|
|
|
|
continue;
|
|
|
|
if (unlikely(dax_is_locked(entry)))
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = get_unlocked_entry(&xas, 0);
|
2018-05-18 01:03:48 +08:00
|
|
|
if (entry)
|
|
|
|
page = dax_busy_page(entry);
|
2021-04-29 03:03:13 +08:00
|
|
|
put_unlocked_entry(&xas, entry, WAKE_NEXT);
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
if (page)
|
|
|
|
break;
|
2018-05-18 01:03:48 +08:00
|
|
|
if (++scanned % XA_CHECK_SCHED)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
xas_pause(&xas);
|
|
|
|
xas_unlock_irq(&xas);
|
|
|
|
cond_resched();
|
|
|
|
xas_lock_irq(&xas);
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
}
|
2018-05-18 01:03:48 +08:00
|
|
|
xas_unlock_irq(&xas);
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
return page;
|
|
|
|
}
|
2020-03-04 03:58:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dax_layout_busy_page_range);
|
|
|
|
|
|
|
|
struct page *dax_layout_busy_page(struct address_space *mapping)
|
|
|
|
{
|
|
|
|
return dax_layout_busy_page_range(mapping, 0, LLONG_MAX);
|
|
|
|
}
|
mm, fs, dax: handle layout changes to pinned dax mappings
Background:
get_user_pages() in the filesystem pins file backed memory pages for
access by devices performing dma. However, it only pins the memory pages
not the page-to-file offset association. If a file is truncated the
pages are mapped out of the file and dma may continue indefinitely into
a page that is owned by a device driver. This breaks coherency of the
file vs dma, but the assumption is that if userspace wants the
file-space truncated it does not matter what data is inbound from the
device, it is not relevant anymore. The only expectation is that dma can
safely continue while the filesystem reallocates the block(s).
Problem:
This expectation that dma can safely continue while the filesystem
changes the block map is broken by dax. With dax the target dma page
*is* the filesystem block. The model of leaving the page pinned for dma,
but truncating the file block out of the file, means that the filesytem
is free to reallocate a block under active dma to another file and now
the expected data-incoherency situation has turned into active
data-corruption.
Solution:
Defer all filesystem operations (fallocate(), truncate()) on a dax mode
file while any page/block in the file is under active dma. This solution
assumes that dma is transient. Cases where dma operations are known to
not be transient, like RDMA, have been explicitly disabled via
commits like 5f1d43de5416 "IB/core: disable memory registration of
filesystem-dax vmas".
The dax_layout_busy_page() routine is called by filesystems with a lock
held against mm faults (i_mmap_lock) to find pinned / busy dax pages.
The process of looking up a busy page invalidates all mappings
to trigger any subsequent get_user_pages() to block on i_mmap_lock.
The filesystem continues to call dax_layout_busy_page() until it finally
returns no more active pages. This approach assumes that the page
pinning is transient, if that assumption is violated the system would
have likely hung from the uncompleted I/O.
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2018-03-10 09:44:31 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dax_layout_busy_page);
|
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
static int __dax_invalidate_entry(struct address_space *mapping,
|
2016-08-10 23:22:44 +08:00
|
|
|
pgoff_t index, bool trunc)
|
|
|
|
{
|
2018-03-29 03:40:41 +08:00
|
|
|
XA_STATE(xas, &mapping->i_pages, index);
|
2016-08-10 23:22:44 +08:00
|
|
|
int ret = 0;
|
|
|
|
void *entry;
|
|
|
|
|
2018-03-29 03:40:41 +08:00
|
|
|
xas_lock_irq(&xas);
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = get_unlocked_entry(&xas, 0);
|
2017-11-04 01:30:42 +08:00
|
|
|
if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
|
2016-08-10 23:22:44 +08:00
|
|
|
goto out;
|
|
|
|
if (!trunc &&
|
2018-03-29 03:40:41 +08:00
|
|
|
(xas_get_mark(&xas, PAGECACHE_TAG_DIRTY) ||
|
|
|
|
xas_get_mark(&xas, PAGECACHE_TAG_TOWRITE)))
|
2016-08-10 23:22:44 +08:00
|
|
|
goto out;
|
2017-12-23 14:02:48 +08:00
|
|
|
dax_disassociate_entry(entry, mapping, trunc);
|
2018-03-29 03:40:41 +08:00
|
|
|
xas_store(&xas, NULL);
|
2021-05-05 09:32:51 +08:00
|
|
|
mapping->nrpages -= 1UL << dax_entry_order(entry);
|
2016-08-10 23:22:44 +08:00
|
|
|
ret = 1;
|
|
|
|
out:
|
dax: Wake up all waiters after invalidating dax entry
I am seeing missed wakeups which ultimately lead to a deadlock when I am
using virtiofs with DAX enabled and running "make -j". I had to mount
virtiofs as rootfs and also reduce to dax window size to 256M to reproduce
the problem consistently.
So here is the problem. put_unlocked_entry() wakes up waiters only
if entry is not null as well as !dax_is_conflict(entry). But if I
call multiple instances of invalidate_inode_pages2() in parallel,
then I can run into a situation where there are waiters on
this index but nobody will wake these waiters.
invalidate_inode_pages2()
invalidate_inode_pages2_range()
invalidate_exceptional_entry2()
dax_invalidate_mapping_entry_sync()
__dax_invalidate_entry() {
xas_lock_irq(&xas);
entry = get_unlocked_entry(&xas, 0);
...
...
dax_disassociate_entry(entry, mapping, trunc);
xas_store(&xas, NULL);
...
...
put_unlocked_entry(&xas, entry);
xas_unlock_irq(&xas);
}
Say a fault in in progress and it has locked entry at offset say "0x1c".
Now say three instances of invalidate_inode_pages2() are in progress
(A, B, C) and they all try to invalidate entry at offset "0x1c". Given
dax entry is locked, all tree instances A, B, C will wait in wait queue.
When dax fault finishes, say A is woken up. It will store NULL entry
at index "0x1c" and wake up B. When B comes along it will find "entry=0"
at page offset 0x1c and it will call put_unlocked_entry(&xas, 0). And
this means put_unlocked_entry() will not wake up next waiter, given
the current code. And that means C continues to wait and is not woken
up.
This patch fixes the issue by waking up all waiters when a dax entry
has been invalidated. This seems to fix the deadlock I am facing
and I can make forward progress.
Reported-by: Sergio Lopez <slp@redhat.com>
Fixes: ac401cc78242 ("dax: New fault locking")
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Link: https://lore.kernel.org/r/20210428190314.1865312-4-vgoyal@redhat.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-04-29 03:03:14 +08:00
|
|
|
put_unlocked_entry(&xas, entry, WAKE_ALL);
|
2018-03-29 03:40:41 +08:00
|
|
|
xas_unlock_irq(&xas);
|
2016-08-10 23:22:44 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2018-03-29 03:40:41 +08:00
|
|
|
|
2016-05-13 00:29:18 +08:00
|
|
|
/*
|
2017-11-04 01:30:42 +08:00
|
|
|
* Delete DAX entry at @index from @mapping. Wait for it
|
|
|
|
* to be unlocked before deleting it.
|
2016-05-13 00:29:18 +08:00
|
|
|
*/
|
|
|
|
int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index)
|
|
|
|
{
|
2018-03-28 01:39:38 +08:00
|
|
|
int ret = __dax_invalidate_entry(mapping, index, true);
|
2016-05-13 00:29:18 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This gets called from truncate / punch_hole path. As such, the caller
|
|
|
|
* must hold locks protecting against concurrent modifications of the
|
2018-03-28 01:39:38 +08:00
|
|
|
* page cache (usually fs-private i_mmap_sem for writing). Since the
|
2017-11-04 01:30:42 +08:00
|
|
|
* caller has seen a DAX entry for this index, we better find it
|
2016-05-13 00:29:18 +08:00
|
|
|
* at that index as well...
|
|
|
|
*/
|
2016-08-10 23:22:44 +08:00
|
|
|
WARN_ON_ONCE(!ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2017-11-04 01:30:42 +08:00
|
|
|
* Invalidate DAX entry if it is clean.
|
2016-08-10 23:22:44 +08:00
|
|
|
*/
|
|
|
|
int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
|
|
|
|
pgoff_t index)
|
|
|
|
{
|
2018-03-28 01:39:38 +08:00
|
|
|
return __dax_invalidate_entry(mapping, index, false);
|
2016-05-13 00:29:18 +08:00
|
|
|
}
|
|
|
|
|
2021-11-29 18:21:48 +08:00
|
|
|
static pgoff_t dax_iomap_pgoff(const struct iomap *iomap, loff_t pos)
|
2015-02-17 07:59:02 +08:00
|
|
|
{
|
2021-11-29 18:22:00 +08:00
|
|
|
return PHYS_PFN(iomap->addr + (pos & PAGE_MASK) - iomap->offset);
|
2021-11-29 18:21:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int copy_cow_page_dax(struct vm_fault *vmf, const struct iomap_iter *iter)
|
|
|
|
{
|
2021-11-29 18:21:48 +08:00
|
|
|
pgoff_t pgoff = dax_iomap_pgoff(&iter->iomap, iter->pos);
|
2017-01-28 05:31:42 +08:00
|
|
|
void *vto, *kaddr;
|
|
|
|
long rc;
|
|
|
|
int id;
|
|
|
|
|
|
|
|
id = dax_read_lock();
|
2021-11-29 18:21:47 +08:00
|
|
|
rc = dax_direct_access(iter->iomap.dax_dev, pgoff, 1, &kaddr, NULL);
|
2017-01-28 05:31:42 +08:00
|
|
|
if (rc < 0) {
|
|
|
|
dax_read_unlock(id);
|
|
|
|
return rc;
|
|
|
|
}
|
2021-11-29 18:21:47 +08:00
|
|
|
vto = kmap_atomic(vmf->cow_page);
|
|
|
|
copy_user_page(vto, kaddr, vmf->address, vmf->cow_page);
|
2015-02-17 07:59:02 +08:00
|
|
|
kunmap_atomic(vto);
|
2017-01-28 05:31:42 +08:00
|
|
|
dax_read_unlock(id);
|
2015-02-17 07:59:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
/*
|
|
|
|
* By this point grab_mapping_entry() has ensured that we have a locked entry
|
|
|
|
* of the appropriate size so we don't have to worry about downgrading PMDs to
|
|
|
|
* PTEs. If we happen to be trying to insert a PTE and there is a PMD
|
|
|
|
* already in the tree, we will skip the insertion and just dirty the PMD as
|
|
|
|
* appropriate.
|
|
|
|
*/
|
2018-03-30 10:58:27 +08:00
|
|
|
static void *dax_insert_entry(struct xa_state *xas,
|
|
|
|
struct address_space *mapping, struct vm_fault *vmf,
|
|
|
|
void *entry, pfn_t pfn, unsigned long flags, bool dirty)
|
2016-01-23 07:10:47 +08:00
|
|
|
{
|
2018-03-30 10:58:27 +08:00
|
|
|
void *new_entry = dax_make_entry(pfn, flags);
|
2016-01-23 07:10:47 +08:00
|
|
|
|
2017-11-01 23:36:40 +08:00
|
|
|
if (dirty)
|
2016-02-06 07:36:55 +08:00
|
|
|
__mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
|
2016-01-23 07:10:47 +08:00
|
|
|
|
2017-11-04 01:30:42 +08:00
|
|
|
if (dax_is_zero_entry(entry) && !(flags & DAX_ZERO_PAGE)) {
|
2018-03-30 10:58:27 +08:00
|
|
|
unsigned long index = xas->xa_index;
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
/* we are replacing a zero page with block mapping */
|
|
|
|
if (dax_is_pmd_entry(entry))
|
2018-02-01 08:17:36 +08:00
|
|
|
unmap_mapping_pages(mapping, index & ~PG_PMD_COLOUR,
|
2018-03-30 10:58:27 +08:00
|
|
|
PG_PMD_NR, false);
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
else /* pte entry */
|
2018-03-30 10:58:27 +08:00
|
|
|
unmap_mapping_pages(mapping, index, 1, false);
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
xas_reset(xas);
|
|
|
|
xas_lock_irq(xas);
|
2019-06-06 17:10:28 +08:00
|
|
|
if (dax_is_zero_entry(entry) || dax_is_empty_entry(entry)) {
|
|
|
|
void *old;
|
|
|
|
|
2017-12-23 14:02:48 +08:00
|
|
|
dax_disassociate_entry(entry, mapping, false);
|
2018-07-14 12:49:50 +08:00
|
|
|
dax_associate_entry(new_entry, mapping, vmf->vma, vmf->address);
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
/*
|
2018-03-28 01:39:38 +08:00
|
|
|
* Only swap our new entry into the page cache if the current
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
* entry is a zero page or an empty entry. If a normal PTE or
|
2018-03-28 01:39:38 +08:00
|
|
|
* PMD entry is already in the cache, we leave it alone. This
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
* means that if we are trying to insert a PTE and the
|
|
|
|
* existing entry is a PMD, we will just leave the PMD in the
|
|
|
|
* tree and dirty it if necessary.
|
|
|
|
*/
|
2019-06-06 17:10:28 +08:00
|
|
|
old = dax_lock_entry(xas, new_entry);
|
2018-03-30 10:58:27 +08:00
|
|
|
WARN_ON_ONCE(old != xa_mk_value(xa_to_value(entry) |
|
|
|
|
DAX_LOCKED));
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
entry = new_entry;
|
2018-03-30 10:58:27 +08:00
|
|
|
} else {
|
|
|
|
xas_load(xas); /* Walk the xa_state */
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
|
2017-11-01 23:36:40 +08:00
|
|
|
if (dirty)
|
2018-03-30 10:58:27 +08:00
|
|
|
xas_set_mark(xas, PAGECACHE_TAG_DIRTY);
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
xas_unlock_irq(xas);
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
return entry;
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
static inline
|
|
|
|
unsigned long pgoff_address(pgoff_t pgoff, struct vm_area_struct *vma)
|
2016-12-15 07:07:53 +08:00
|
|
|
{
|
|
|
|
unsigned long address;
|
|
|
|
|
|
|
|
address = vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT);
|
|
|
|
VM_BUG_ON_VMA(address < vma->vm_start || address >= vma->vm_end, vma);
|
|
|
|
return address;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Walk all mappings of a given index of a file and writeprotect them */
|
2018-03-28 01:39:38 +08:00
|
|
|
static void dax_entry_mkclean(struct address_space *mapping, pgoff_t index,
|
|
|
|
unsigned long pfn)
|
2016-12-15 07:07:53 +08:00
|
|
|
{
|
|
|
|
struct vm_area_struct *vma;
|
2017-01-11 08:57:24 +08:00
|
|
|
pte_t pte, *ptep = NULL;
|
|
|
|
pmd_t *pmdp = NULL;
|
2016-12-15 07:07:53 +08:00
|
|
|
spinlock_t *ptl;
|
|
|
|
|
|
|
|
i_mmap_lock_read(mapping);
|
|
|
|
vma_interval_tree_foreach(vma, &mapping->i_mmap, index, index) {
|
2018-12-28 16:38:09 +08:00
|
|
|
struct mmu_notifier_range range;
|
|
|
|
unsigned long address;
|
2016-12-15 07:07:53 +08:00
|
|
|
|
|
|
|
cond_resched();
|
|
|
|
|
|
|
|
if (!(vma->vm_flags & VM_SHARED))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
address = pgoff_address(index, vma);
|
2017-09-01 05:17:26 +08:00
|
|
|
|
|
|
|
/*
|
2021-02-05 18:07:11 +08:00
|
|
|
* follow_invalidate_pte() will use the range to call
|
2020-12-16 12:47:23 +08:00
|
|
|
* mmu_notifier_invalidate_range_start() on our behalf before
|
|
|
|
* taking any lock.
|
2017-09-01 05:17:26 +08:00
|
|
|
*/
|
2021-02-05 18:07:11 +08:00
|
|
|
if (follow_invalidate_pte(vma->vm_mm, address, &range, &ptep,
|
|
|
|
&pmdp, &ptl))
|
2016-12-15 07:07:53 +08:00
|
|
|
continue;
|
|
|
|
|
2017-11-16 09:34:07 +08:00
|
|
|
/*
|
|
|
|
* No need to call mmu_notifier_invalidate_range() as we are
|
|
|
|
* downgrading page table protection not changing it to point
|
|
|
|
* to a new page.
|
|
|
|
*
|
2018-03-22 03:22:47 +08:00
|
|
|
* See Documentation/vm/mmu_notifier.rst
|
2017-11-16 09:34:07 +08:00
|
|
|
*/
|
2017-01-11 08:57:24 +08:00
|
|
|
if (pmdp) {
|
|
|
|
#ifdef CONFIG_FS_DAX_PMD
|
|
|
|
pmd_t pmd;
|
|
|
|
|
|
|
|
if (pfn != pmd_pfn(*pmdp))
|
|
|
|
goto unlock_pmd;
|
Revert "mm: replace p??_write with pte_access_permitted in fault + gup paths"
This reverts commits 5c9d2d5c269c, c7da82b894e9, and e7fe7b5cae90.
We'll probably need to revisit this, but basically we should not
complicate the get_user_pages_fast() case, and checking the actual page
table protection key bits will require more care anyway, since the
protection keys depend on the exact state of the VM in question.
Particularly when doing a "remote" page lookup (ie in somebody elses VM,
not your own), you need to be much more careful than this was. Dave
Hansen says:
"So, the underlying bug here is that we now a get_user_pages_remote()
and then go ahead and do the p*_access_permitted() checks against the
current PKRU. This was introduced recently with the addition of the
new p??_access_permitted() calls.
We have checks in the VMA path for the "remote" gups and we avoid
consulting PKRU for them. This got missed in the pkeys selftests
because I did a ptrace read, but not a *write*. I also didn't
explicitly test it against something where a COW needed to be done"
It's also not entirely clear that it makes sense to check the protection
key bits at this level at all. But one possible eventual solution is to
make the get_user_pages_fast() case just abort if it sees protection key
bits set, which makes us fall back to the regular get_user_pages() case,
which then has a vma and can do the check there if we want to.
We'll see.
Somewhat related to this all: what we _do_ want to do some day is to
check the PAGE_USER bit - it should obviously always be set for user
pages, but it would be a good check to have back. Because we have no
generic way to test for it, we lost it as part of moving over from the
architecture-specific x86 GUP implementation to the generic one in
commit e585513b76f7 ("x86/mm/gup: Switch GUP to the generic
get_user_page_fast() implementation").
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-12-16 10:53:22 +08:00
|
|
|
if (!pmd_dirty(*pmdp) && !pmd_write(*pmdp))
|
2017-01-11 08:57:24 +08:00
|
|
|
goto unlock_pmd;
|
|
|
|
|
2022-04-29 14:16:09 +08:00
|
|
|
flush_cache_range(vma, address,
|
|
|
|
address + HPAGE_PMD_SIZE);
|
2019-05-14 08:19:11 +08:00
|
|
|
pmd = pmdp_invalidate(vma, address, pmdp);
|
2017-01-11 08:57:24 +08:00
|
|
|
pmd = pmd_wrprotect(pmd);
|
|
|
|
pmd = pmd_mkclean(pmd);
|
|
|
|
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
|
|
|
|
unlock_pmd:
|
|
|
|
#endif
|
2018-02-01 08:14:04 +08:00
|
|
|
spin_unlock(ptl);
|
2017-01-11 08:57:24 +08:00
|
|
|
} else {
|
|
|
|
if (pfn != pte_pfn(*ptep))
|
|
|
|
goto unlock_pte;
|
|
|
|
if (!pte_dirty(*ptep) && !pte_write(*ptep))
|
|
|
|
goto unlock_pte;
|
|
|
|
|
|
|
|
flush_cache_page(vma, address, pfn);
|
|
|
|
pte = ptep_clear_flush(vma, address, ptep);
|
|
|
|
pte = pte_wrprotect(pte);
|
|
|
|
pte = pte_mkclean(pte);
|
|
|
|
set_pte_at(vma->vm_mm, address, ptep, pte);
|
|
|
|
unlock_pte:
|
|
|
|
pte_unmap_unlock(ptep, ptl);
|
|
|
|
}
|
2016-12-15 07:07:53 +08:00
|
|
|
|
2018-12-28 16:38:09 +08:00
|
|
|
mmu_notifier_invalidate_range_end(&range);
|
2016-12-15 07:07:53 +08:00
|
|
|
}
|
|
|
|
i_mmap_unlock_read(mapping);
|
|
|
|
}
|
|
|
|
|
2018-03-29 04:03:45 +08:00
|
|
|
static int dax_writeback_one(struct xa_state *xas, struct dax_device *dax_dev,
|
|
|
|
struct address_space *mapping, void *entry)
|
2016-01-23 07:10:47 +08:00
|
|
|
{
|
2019-03-02 03:12:41 +08:00
|
|
|
unsigned long pfn, index, count;
|
2017-10-15 08:13:45 +08:00
|
|
|
long ret = 0;
|
2016-01-23 07:10:47 +08:00
|
|
|
|
|
|
|
/*
|
2016-12-15 07:07:47 +08:00
|
|
|
* A page got tagged dirty in DAX mapping? Something is seriously
|
|
|
|
* wrong.
|
2016-01-23 07:10:47 +08:00
|
|
|
*/
|
2017-11-04 01:30:42 +08:00
|
|
|
if (WARN_ON(!xa_is_value(entry)))
|
2016-12-15 07:07:47 +08:00
|
|
|
return -EIO;
|
2016-01-23 07:10:47 +08:00
|
|
|
|
2018-03-29 04:03:45 +08:00
|
|
|
if (unlikely(dax_is_locked(entry))) {
|
|
|
|
void *old_entry = entry;
|
|
|
|
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = get_unlocked_entry(xas, 0);
|
2018-03-29 04:03:45 +08:00
|
|
|
|
|
|
|
/* Entry got punched out / reallocated? */
|
|
|
|
if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
|
|
|
|
goto put_unlocked;
|
|
|
|
/*
|
|
|
|
* Entry got reallocated elsewhere? No need to writeback.
|
|
|
|
* We have to compare pfns as we must not bail out due to
|
|
|
|
* difference in lockbit or entry type.
|
|
|
|
*/
|
|
|
|
if (dax_to_pfn(old_entry) != dax_to_pfn(entry))
|
|
|
|
goto put_unlocked;
|
|
|
|
if (WARN_ON_ONCE(dax_is_empty_entry(entry) ||
|
|
|
|
dax_is_zero_entry(entry))) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto put_unlocked;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Another fsync thread may have already done this entry */
|
|
|
|
if (!xas_get_mark(xas, PAGECACHE_TAG_TOWRITE))
|
|
|
|
goto put_unlocked;
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
|
|
|
|
2016-12-15 07:07:47 +08:00
|
|
|
/* Lock the entry to serialize with page faults */
|
2018-03-29 04:03:45 +08:00
|
|
|
dax_lock_entry(xas, entry);
|
|
|
|
|
2016-12-15 07:07:47 +08:00
|
|
|
/*
|
|
|
|
* We can clear the tag now but we have to be careful so that concurrent
|
|
|
|
* dax_writeback_one() calls for the same index cannot finish before we
|
|
|
|
* actually flush the caches. This is achieved as the calls will look
|
2018-04-11 07:36:56 +08:00
|
|
|
* at the entry only under the i_pages lock and once they do that
|
|
|
|
* they will see the entry locked and wait for it to unlock.
|
2016-12-15 07:07:47 +08:00
|
|
|
*/
|
2018-03-29 04:03:45 +08:00
|
|
|
xas_clear_mark(xas, PAGECACHE_TAG_TOWRITE);
|
|
|
|
xas_unlock_irq(xas);
|
2016-12-15 07:07:47 +08:00
|
|
|
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
/*
|
2019-03-02 03:12:41 +08:00
|
|
|
* If dax_writeback_mapping_range() was given a wbc->range_start
|
|
|
|
* in the middle of a PMD, the 'index' we use needs to be
|
|
|
|
* aligned to the start of the PMD.
|
2017-10-15 08:13:45 +08:00
|
|
|
* This allows us to flush for PMD_SIZE and not have to worry about
|
|
|
|
* partial PMD writebacks.
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
*/
|
2018-03-28 01:39:38 +08:00
|
|
|
pfn = dax_to_pfn(entry);
|
2019-03-02 03:12:41 +08:00
|
|
|
count = 1UL << dax_entry_order(entry);
|
|
|
|
index = xas->xa_index & ~(count - 1);
|
2017-01-28 05:31:42 +08:00
|
|
|
|
2019-03-02 03:12:41 +08:00
|
|
|
dax_entry_mkclean(mapping, index, pfn);
|
|
|
|
dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
|
2016-12-15 07:07:53 +08:00
|
|
|
/*
|
|
|
|
* After we have flushed the cache, we can clear the dirty tag. There
|
|
|
|
* cannot be new dirty data in the pfn after the flush has completed as
|
|
|
|
* the pfn mappings are writeprotected and fault waits for mapping
|
|
|
|
* entry lock.
|
|
|
|
*/
|
2018-03-29 04:03:45 +08:00
|
|
|
xas_reset(xas);
|
|
|
|
xas_lock_irq(xas);
|
|
|
|
xas_store(xas, entry);
|
|
|
|
xas_clear_mark(xas, PAGECACHE_TAG_DIRTY);
|
2021-04-29 03:03:12 +08:00
|
|
|
dax_wake_entry(xas, entry, WAKE_NEXT);
|
2018-03-29 04:03:45 +08:00
|
|
|
|
2019-03-02 03:12:41 +08:00
|
|
|
trace_dax_writeback_one(mapping->host, index, count);
|
2016-01-23 07:10:47 +08:00
|
|
|
return ret;
|
|
|
|
|
2016-12-15 07:07:47 +08:00
|
|
|
put_unlocked:
|
2021-04-29 03:03:13 +08:00
|
|
|
put_unlocked_entry(xas, entry, WAKE_NEXT);
|
2016-01-23 07:10:47 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flush the mapping to the persistent domain within the byte range of [start,
|
|
|
|
* end]. This is required by data integrity operations to ensure file data is
|
|
|
|
* on persistent storage prior to completion of the operation.
|
|
|
|
*/
|
2016-02-27 07:19:55 +08:00
|
|
|
int dax_writeback_mapping_range(struct address_space *mapping,
|
2020-01-04 02:33:07 +08:00
|
|
|
struct dax_device *dax_dev, struct writeback_control *wbc)
|
2016-01-23 07:10:47 +08:00
|
|
|
{
|
2018-03-29 04:03:45 +08:00
|
|
|
XA_STATE(xas, &mapping->i_pages, wbc->range_start >> PAGE_SHIFT);
|
2016-01-23 07:10:47 +08:00
|
|
|
struct inode *inode = mapping->host;
|
2018-03-29 04:03:45 +08:00
|
|
|
pgoff_t end_index = wbc->range_end >> PAGE_SHIFT;
|
|
|
|
void *entry;
|
|
|
|
int ret = 0;
|
|
|
|
unsigned int scanned = 0;
|
2016-01-23 07:10:47 +08:00
|
|
|
|
|
|
|
if (WARN_ON_ONCE(inode->i_blkbits != PAGE_SHIFT))
|
|
|
|
return -EIO;
|
|
|
|
|
2021-05-05 09:32:45 +08:00
|
|
|
if (mapping_empty(mapping) || wbc->sync_mode != WB_SYNC_ALL)
|
2016-02-27 07:19:55 +08:00
|
|
|
return 0;
|
|
|
|
|
2018-03-29 04:03:45 +08:00
|
|
|
trace_dax_writeback_range(inode, xas.xa_index, end_index);
|
2016-01-23 07:10:47 +08:00
|
|
|
|
2018-03-29 04:03:45 +08:00
|
|
|
tag_pages_for_writeback(mapping, xas.xa_index, end_index);
|
2016-01-23 07:10:47 +08:00
|
|
|
|
2018-03-29 04:03:45 +08:00
|
|
|
xas_lock_irq(&xas);
|
|
|
|
xas_for_each_marked(&xas, entry, end_index, PAGECACHE_TAG_TOWRITE) {
|
|
|
|
ret = dax_writeback_one(&xas, dax_dev, mapping, entry);
|
|
|
|
if (ret < 0) {
|
|
|
|
mapping_set_error(mapping, ret);
|
2016-01-23 07:10:47 +08:00
|
|
|
break;
|
|
|
|
}
|
2018-03-29 04:03:45 +08:00
|
|
|
if (++scanned % XA_CHECK_SCHED)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
xas_pause(&xas);
|
|
|
|
xas_unlock_irq(&xas);
|
|
|
|
cond_resched();
|
|
|
|
xas_lock_irq(&xas);
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
2018-03-29 04:03:45 +08:00
|
|
|
xas_unlock_irq(&xas);
|
|
|
|
trace_dax_writeback_range_done(inode, xas.xa_index, end_index);
|
|
|
|
return ret;
|
2016-01-23 07:10:47 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dax_writeback_mapping_range);
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
static int dax_iomap_pfn(const struct iomap *iomap, loff_t pos, size_t size,
|
2017-11-01 23:36:33 +08:00
|
|
|
pfn_t *pfnp)
|
2015-02-17 07:59:02 +08:00
|
|
|
{
|
2021-11-29 18:21:48 +08:00
|
|
|
pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
|
2017-01-28 05:31:42 +08:00
|
|
|
int id, rc;
|
2017-11-01 23:36:33 +08:00
|
|
|
long length;
|
2015-02-17 07:59:02 +08:00
|
|
|
|
2017-01-28 05:31:42 +08:00
|
|
|
id = dax_read_lock();
|
2017-11-01 23:36:33 +08:00
|
|
|
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
|
2018-07-30 15:15:48 +08:00
|
|
|
NULL, pfnp);
|
2017-11-01 23:36:33 +08:00
|
|
|
if (length < 0) {
|
|
|
|
rc = length;
|
|
|
|
goto out;
|
2017-01-28 05:31:42 +08:00
|
|
|
}
|
2017-11-01 23:36:33 +08:00
|
|
|
rc = -EINVAL;
|
|
|
|
if (PFN_PHYS(length) < size)
|
|
|
|
goto out;
|
|
|
|
if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1))
|
|
|
|
goto out;
|
|
|
|
/* For larger pages we need devmap */
|
|
|
|
if (length > 1 && !pfn_t_devmap(*pfnp))
|
|
|
|
goto out;
|
|
|
|
rc = 0;
|
|
|
|
out:
|
2017-01-28 05:31:42 +08:00
|
|
|
dax_read_unlock(id);
|
2017-11-01 23:36:33 +08:00
|
|
|
return rc;
|
2015-04-16 07:15:14 +08:00
|
|
|
}
|
|
|
|
|
2017-09-07 07:18:39 +08:00
|
|
|
/*
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
* The user has performed a load from a hole in the file. Allocating a new
|
|
|
|
* page in the file would cause excessive storage usage for workloads with
|
|
|
|
* sparse files. Instead we insert a read-only mapping of the 4k zero page.
|
|
|
|
* If this page is ever written to we will re-fault and change the mapping to
|
|
|
|
* point to real DAX storage instead.
|
2017-09-07 07:18:39 +08:00
|
|
|
*/
|
2018-03-30 10:58:27 +08:00
|
|
|
static vm_fault_t dax_load_hole(struct xa_state *xas,
|
|
|
|
struct address_space *mapping, void **entry,
|
|
|
|
struct vm_fault *vmf)
|
2017-09-07 07:18:39 +08:00
|
|
|
{
|
|
|
|
struct inode *inode = mapping->host;
|
dax: use common 4k zero page for dax mmap reads
When servicing mmap() reads from file holes the current DAX code
allocates a page cache page of all zeroes and places the struct page
pointer in the mapping->page_tree radix tree.
This has three major drawbacks:
1) It consumes memory unnecessarily. For every 4k page that is read via
a DAX mmap() over a hole, we allocate a new page cache page. This
means that if you read 1GiB worth of pages, you end up using 1GiB of
zeroed memory. This is easily visible by looking at the overall
memory consumption of the system or by looking at /proc/[pid]/smaps:
7f62e72b3000-7f63272b3000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 1048576 kB
Pss: 1048576 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1048576 kB
Private_Dirty: 0 kB
Referenced: 1048576 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
2) It is slower than using a common zero page because each page fault
has more work to do. Instead of just inserting a common zero page we
have to allocate a page cache page, zero it, and then insert it. Here
are the average latencies of dax_load_hole() as measured by ftrace on
a random test box:
Old method, using zeroed page cache pages: 3.4 us
New method, using the common 4k zero page: 0.8 us
This was the average latency over 1 GiB of sequential reads done by
this simple fio script:
[global]
size=1G
filename=/root/dax/data
fallocate=none
[io]
rw=read
ioengine=mmap
3) The fact that we had to check for both DAX exceptional entries and
for page cache pages in the radix tree made the DAX code more
complex.
Solve these issues by following the lead of the DAX PMD code and using a
common 4k zero page instead. As with the PMD code we will now insert a
DAX exceptional entry into the radix tree instead of a struct page
pointer which allows us to remove all the special casing in the DAX
code.
Note that we do still pretty aggressively check for regular pages in the
DAX radix tree, especially where we take action based on the bits set in
the page. If we ever find a regular page in our radix tree now that
most likely means that someone besides DAX is inserting pages (which has
happened lots of times in the past), and we want to find that out early
and fail loudly.
This solution also removes the extra memory consumption. Here is that
same /proc/[pid]/smaps after 1GiB of reading from a hole with the new
code:
7f2054a74000-7f2094a74000 rw-s 00000000 103:00 12 /root/dax/data
Size: 1048576 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
Overall system memory consumption is similarly improved.
Another major change is that we remove dax_pfn_mkwrite() from our fault
flow, and instead rely on the page fault itself to make the PTE dirty
and writeable. The following description from the patch adding the
vm_insert_mixed_mkwrite() call explains this a little more:
"To be able to use the common 4k zero page in DAX we need to have our
PTE fault path look more like our PMD fault path where a PTE entry
can be marked as dirty and writeable as it is first inserted rather
than waiting for a follow-up dax_pfn_mkwrite() =>
finish_mkwrite_fault() call.
Right now we can rely on having a dax_pfn_mkwrite() call because we
can distinguish between these two cases in do_wp_page():
case 1: 4k zero page => writable DAX storage
case 2: read-only DAX storage => writeable DAX storage
This distinction is made by via vm_normal_page(). vm_normal_page()
returns false for the common 4k zero page, though, just as it does
for DAX ptes. Instead of special casing the DAX + 4k zero page case
we will simplify our DAX PTE page fault sequence so that it matches
our DAX PMD sequence, and get rid of the dax_pfn_mkwrite() helper.
We will instead use dax_iomap_fault() to handle write-protection
faults.
This means that insert_pfn() needs to follow the lead of
insert_pfn_pmd() and allow us to pass in a 'mkwrite' flag. If
'mkwrite' is set insert_pfn() will do the work that was previously
done by wp_page_reuse() as part of the dax_pfn_mkwrite() call path"
Link: http://lkml.kernel.org/r/20170724170616.25810-4-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:18:43 +08:00
|
|
|
unsigned long vaddr = vmf->address;
|
2018-09-12 12:27:44 +08:00
|
|
|
pfn_t pfn = pfn_to_pfn_t(my_zero_pfn(vaddr));
|
|
|
|
vm_fault_t ret;
|
2017-09-07 07:18:39 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
*entry = dax_insert_entry(xas, mapping, vmf, *entry, pfn,
|
2017-11-04 01:30:42 +08:00
|
|
|
DAX_ZERO_PAGE, false);
|
|
|
|
|
2018-06-08 08:04:29 +08:00
|
|
|
ret = vmf_insert_mixed(vmf->vma, vaddr, pfn);
|
2017-09-07 07:18:39 +08:00
|
|
|
trace_dax_load_hole(inode, vmf, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
#ifdef CONFIG_FS_DAX_PMD
|
|
|
|
static vm_fault_t dax_pmd_load_hole(struct xa_state *xas, struct vm_fault *vmf,
|
2021-08-11 09:33:15 +08:00
|
|
|
const struct iomap *iomap, void **entry)
|
2021-08-11 09:33:15 +08:00
|
|
|
{
|
|
|
|
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
|
|
|
|
unsigned long pmd_addr = vmf->address & PMD_MASK;
|
|
|
|
struct vm_area_struct *vma = vmf->vma;
|
|
|
|
struct inode *inode = mapping->host;
|
|
|
|
pgtable_t pgtable = NULL;
|
|
|
|
struct page *zero_page;
|
|
|
|
spinlock_t *ptl;
|
|
|
|
pmd_t pmd_entry;
|
|
|
|
pfn_t pfn;
|
|
|
|
|
|
|
|
zero_page = mm_get_huge_zero_page(vmf->vma->vm_mm);
|
|
|
|
|
|
|
|
if (unlikely(!zero_page))
|
|
|
|
goto fallback;
|
|
|
|
|
|
|
|
pfn = page_to_pfn_t(zero_page);
|
|
|
|
*entry = dax_insert_entry(xas, mapping, vmf, *entry, pfn,
|
|
|
|
DAX_PMD | DAX_ZERO_PAGE, false);
|
|
|
|
|
|
|
|
if (arch_needs_pgtable_deposit()) {
|
|
|
|
pgtable = pte_alloc_one(vma->vm_mm);
|
|
|
|
if (!pgtable)
|
|
|
|
return VM_FAULT_OOM;
|
|
|
|
}
|
|
|
|
|
|
|
|
ptl = pmd_lock(vmf->vma->vm_mm, vmf->pmd);
|
|
|
|
if (!pmd_none(*(vmf->pmd))) {
|
|
|
|
spin_unlock(ptl);
|
|
|
|
goto fallback;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pgtable) {
|
|
|
|
pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable);
|
|
|
|
mm_inc_nr_ptes(vma->vm_mm);
|
|
|
|
}
|
|
|
|
pmd_entry = mk_pmd(zero_page, vmf->vma->vm_page_prot);
|
|
|
|
pmd_entry = pmd_mkhuge(pmd_entry);
|
|
|
|
set_pmd_at(vmf->vma->vm_mm, pmd_addr, vmf->pmd, pmd_entry);
|
|
|
|
spin_unlock(ptl);
|
|
|
|
trace_dax_pmd_load_hole(inode, vmf, zero_page, *entry);
|
|
|
|
return VM_FAULT_NOPAGE;
|
|
|
|
|
|
|
|
fallback:
|
|
|
|
if (pgtable)
|
|
|
|
pte_free(vma->vm_mm, pgtable);
|
|
|
|
trace_dax_pmd_load_hole_fallback(inode, vmf, zero_page, *entry);
|
|
|
|
return VM_FAULT_FALLBACK;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static vm_fault_t dax_pmd_load_hole(struct xa_state *xas, struct vm_fault *vmf,
|
2021-08-11 09:33:15 +08:00
|
|
|
const struct iomap *iomap, void **entry)
|
2021-08-11 09:33:15 +08:00
|
|
|
{
|
|
|
|
return VM_FAULT_FALLBACK;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_FS_DAX_PMD */
|
|
|
|
|
2021-11-29 18:21:51 +08:00
|
|
|
static int dax_memzero(struct dax_device *dax_dev, pgoff_t pgoff,
|
|
|
|
unsigned int offset, size_t size)
|
|
|
|
{
|
|
|
|
void *kaddr;
|
|
|
|
long ret;
|
|
|
|
|
|
|
|
ret = dax_direct_access(dax_dev, pgoff, 1, &kaddr, NULL);
|
|
|
|
if (ret > 0) {
|
|
|
|
memset(kaddr + offset, 0, size);
|
|
|
|
dax_flush(dax_dev, kaddr + offset, size);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-11-29 18:21:52 +08:00
|
|
|
static s64 dax_zero_iter(struct iomap_iter *iter, bool *did_zero)
|
2016-05-09 16:47:04 +08:00
|
|
|
{
|
2021-11-29 18:21:52 +08:00
|
|
|
const struct iomap *iomap = &iter->iomap;
|
|
|
|
const struct iomap *srcmap = iomap_iter_srcmap(iter);
|
|
|
|
loff_t pos = iter->pos;
|
|
|
|
u64 length = iomap_length(iter);
|
|
|
|
s64 written = 0;
|
|
|
|
|
|
|
|
/* already zeroed? we're done. */
|
|
|
|
if (srcmap->type == IOMAP_HOLE || srcmap->type == IOMAP_UNWRITTEN)
|
|
|
|
return length;
|
|
|
|
|
|
|
|
do {
|
|
|
|
unsigned offset = offset_in_page(pos);
|
|
|
|
unsigned size = min_t(u64, PAGE_SIZE - offset, length);
|
|
|
|
pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
|
|
|
|
long rc;
|
|
|
|
int id;
|
|
|
|
|
|
|
|
id = dax_read_lock();
|
|
|
|
if (IS_ALIGNED(pos, PAGE_SIZE) && size == PAGE_SIZE)
|
|
|
|
rc = dax_zero_page_range(iomap->dax_dev, pgoff, 1);
|
|
|
|
else
|
|
|
|
rc = dax_memzero(iomap->dax_dev, pgoff, offset, size);
|
|
|
|
dax_read_unlock(id);
|
2017-01-28 05:31:42 +08:00
|
|
|
|
2021-11-29 18:21:52 +08:00
|
|
|
if (rc < 0)
|
|
|
|
return rc;
|
|
|
|
pos += size;
|
|
|
|
length -= size;
|
|
|
|
written += size;
|
|
|
|
if (did_zero)
|
|
|
|
*did_zero = true;
|
|
|
|
} while (length > 0);
|
2021-11-29 18:21:51 +08:00
|
|
|
|
2021-11-29 18:21:52 +08:00
|
|
|
return written;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dax_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
|
|
|
|
const struct iomap_ops *ops)
|
|
|
|
{
|
|
|
|
struct iomap_iter iter = {
|
|
|
|
.inode = inode,
|
|
|
|
.pos = pos,
|
|
|
|
.len = len,
|
2021-11-29 18:21:58 +08:00
|
|
|
.flags = IOMAP_DAX | IOMAP_ZERO,
|
2021-11-29 18:21:52 +08:00
|
|
|
};
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
while ((ret = iomap_iter(&iter, ops)) > 0)
|
|
|
|
iter.processed = dax_zero_iter(&iter, did_zero);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dax_zero_range);
|
|
|
|
|
|
|
|
int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
|
|
|
|
const struct iomap_ops *ops)
|
|
|
|
{
|
|
|
|
unsigned int blocksize = i_blocksize(inode);
|
|
|
|
unsigned int off = pos & (blocksize - 1);
|
|
|
|
|
|
|
|
/* Block boundary? Nothing to do */
|
|
|
|
if (!off)
|
|
|
|
return 0;
|
|
|
|
return dax_zero_range(inode, pos, blocksize - off, did_zero, ops);
|
2016-05-09 16:47:04 +08:00
|
|
|
}
|
2021-11-29 18:21:52 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dax_truncate_page);
|
2016-05-09 16:47:04 +08:00
|
|
|
|
2021-08-11 09:33:13 +08:00
|
|
|
static loff_t dax_iomap_iter(const struct iomap_iter *iomi,
|
|
|
|
struct iov_iter *iter)
|
2016-09-19 09:24:49 +08:00
|
|
|
{
|
2021-08-11 09:33:13 +08:00
|
|
|
const struct iomap *iomap = &iomi->iomap;
|
|
|
|
loff_t length = iomap_length(iomi);
|
|
|
|
loff_t pos = iomi->pos;
|
2017-01-28 05:31:42 +08:00
|
|
|
struct dax_device *dax_dev = iomap->dax_dev;
|
2016-09-19 09:24:49 +08:00
|
|
|
loff_t end = pos + length, done = 0;
|
|
|
|
ssize_t ret = 0;
|
2018-03-17 08:36:44 +08:00
|
|
|
size_t xfer;
|
2017-01-28 05:31:42 +08:00
|
|
|
int id;
|
2016-09-19 09:24:49 +08:00
|
|
|
|
|
|
|
if (iov_iter_rw(iter) == READ) {
|
2021-08-11 09:33:13 +08:00
|
|
|
end = min(end, i_size_read(iomi->inode));
|
2016-09-19 09:24:49 +08:00
|
|
|
if (pos >= end)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (iomap->type == IOMAP_HOLE || iomap->type == IOMAP_UNWRITTEN)
|
|
|
|
return iov_iter_zero(min(length, end - pos), iter);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(iomap->type != IOMAP_MAPPED))
|
|
|
|
return -EIO;
|
|
|
|
|
2016-08-10 23:10:28 +08:00
|
|
|
/*
|
|
|
|
* Write can allocate block for an area which has a hole page mapped
|
|
|
|
* into page tables. We have to tear down these mappings so that data
|
|
|
|
* written by write(2) is visible in mmap.
|
|
|
|
*/
|
2017-05-13 06:46:50 +08:00
|
|
|
if (iomap->flags & IOMAP_F_NEW) {
|
2021-08-11 09:33:13 +08:00
|
|
|
invalidate_inode_pages2_range(iomi->inode->i_mapping,
|
2016-08-10 23:10:28 +08:00
|
|
|
pos >> PAGE_SHIFT,
|
|
|
|
(end - 1) >> PAGE_SHIFT);
|
|
|
|
}
|
|
|
|
|
2017-01-28 05:31:42 +08:00
|
|
|
id = dax_read_lock();
|
2016-09-19 09:24:49 +08:00
|
|
|
while (pos < end) {
|
|
|
|
unsigned offset = pos & (PAGE_SIZE - 1);
|
2017-01-28 05:31:42 +08:00
|
|
|
const size_t size = ALIGN(length + offset, PAGE_SIZE);
|
2021-11-29 18:21:48 +08:00
|
|
|
pgoff_t pgoff = dax_iomap_pgoff(iomap, pos);
|
2016-09-19 09:24:49 +08:00
|
|
|
ssize_t map_len;
|
2017-01-28 05:31:42 +08:00
|
|
|
void *kaddr;
|
2016-09-19 09:24:49 +08:00
|
|
|
|
2017-02-04 05:13:26 +08:00
|
|
|
if (fatal_signal_pending(current)) {
|
|
|
|
ret = -EINTR;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-01-28 05:31:42 +08:00
|
|
|
map_len = dax_direct_access(dax_dev, pgoff, PHYS_PFN(size),
|
2018-07-30 15:15:48 +08:00
|
|
|
&kaddr, NULL);
|
2016-09-19 09:24:49 +08:00
|
|
|
if (map_len < 0) {
|
|
|
|
ret = map_len;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-01-28 05:31:42 +08:00
|
|
|
map_len = PFN_PHYS(map_len);
|
|
|
|
kaddr += offset;
|
2016-09-19 09:24:49 +08:00
|
|
|
map_len -= offset;
|
|
|
|
if (map_len > end - pos)
|
|
|
|
map_len = end - pos;
|
|
|
|
|
|
|
|
if (iov_iter_rw(iter) == WRITE)
|
2018-03-17 08:36:44 +08:00
|
|
|
xfer = dax_copy_from_iter(dax_dev, pgoff, kaddr,
|
2017-05-30 12:56:49 +08:00
|
|
|
map_len, iter);
|
2016-09-19 09:24:49 +08:00
|
|
|
else
|
2018-03-17 08:36:44 +08:00
|
|
|
xfer = dax_copy_to_iter(dax_dev, pgoff, kaddr,
|
2018-05-02 21:46:33 +08:00
|
|
|
map_len, iter);
|
2016-09-19 09:24:49 +08:00
|
|
|
|
2018-03-17 08:36:44 +08:00
|
|
|
pos += xfer;
|
|
|
|
length -= xfer;
|
|
|
|
done += xfer;
|
|
|
|
|
|
|
|
if (xfer == 0)
|
|
|
|
ret = -EFAULT;
|
|
|
|
if (xfer < map_len)
|
|
|
|
break;
|
2016-09-19 09:24:49 +08:00
|
|
|
}
|
2017-01-28 05:31:42 +08:00
|
|
|
dax_read_unlock(id);
|
2016-09-19 09:24:49 +08:00
|
|
|
|
|
|
|
return done ? done : ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2016-11-08 08:32:46 +08:00
|
|
|
* dax_iomap_rw - Perform I/O to a DAX file
|
2016-09-19 09:24:49 +08:00
|
|
|
* @iocb: The control block for this I/O
|
|
|
|
* @iter: The addresses to do I/O from or to
|
|
|
|
* @ops: iomap ops passed from the file system
|
|
|
|
*
|
|
|
|
* This function performs read and write operations to directly mapped
|
|
|
|
* persistent memory. The callers needs to take care of read/write exclusion
|
|
|
|
* and evicting any page cache pages in the region under I/O.
|
|
|
|
*/
|
|
|
|
ssize_t
|
2016-11-08 08:32:46 +08:00
|
|
|
dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
|
2017-01-28 15:20:26 +08:00
|
|
|
const struct iomap_ops *ops)
|
2016-09-19 09:24:49 +08:00
|
|
|
{
|
2021-08-11 09:33:13 +08:00
|
|
|
struct iomap_iter iomi = {
|
|
|
|
.inode = iocb->ki_filp->f_mapping->host,
|
|
|
|
.pos = iocb->ki_pos,
|
|
|
|
.len = iov_iter_count(iter),
|
2021-11-29 18:21:58 +08:00
|
|
|
.flags = IOMAP_DAX,
|
2021-08-11 09:33:13 +08:00
|
|
|
};
|
|
|
|
loff_t done = 0;
|
|
|
|
int ret;
|
2016-09-19 09:24:49 +08:00
|
|
|
|
2017-02-09 03:43:13 +08:00
|
|
|
if (iov_iter_rw(iter) == WRITE) {
|
2021-08-11 09:33:13 +08:00
|
|
|
lockdep_assert_held_write(&iomi.inode->i_rwsem);
|
|
|
|
iomi.flags |= IOMAP_WRITE;
|
2017-02-09 03:43:13 +08:00
|
|
|
} else {
|
2021-08-11 09:33:13 +08:00
|
|
|
lockdep_assert_held(&iomi.inode->i_rwsem);
|
2017-02-09 03:43:13 +08:00
|
|
|
}
|
2016-09-19 09:24:49 +08:00
|
|
|
|
2020-02-06 03:15:58 +08:00
|
|
|
if (iocb->ki_flags & IOCB_NOWAIT)
|
2021-08-11 09:33:13 +08:00
|
|
|
iomi.flags |= IOMAP_NOWAIT;
|
2020-02-06 03:15:58 +08:00
|
|
|
|
2021-08-11 09:33:13 +08:00
|
|
|
while ((ret = iomap_iter(&iomi, ops)) > 0)
|
|
|
|
iomi.processed = dax_iomap_iter(&iomi, iter);
|
2016-09-19 09:24:49 +08:00
|
|
|
|
2021-08-11 09:33:13 +08:00
|
|
|
done = iomi.pos - iocb->ki_pos;
|
|
|
|
iocb->ki_pos = iomi.pos;
|
2016-09-19 09:24:49 +08:00
|
|
|
return done ? done : ret;
|
|
|
|
}
|
2016-11-08 08:32:46 +08:00
|
|
|
EXPORT_SYMBOL_GPL(dax_iomap_rw);
|
2016-09-19 09:24:50 +08:00
|
|
|
|
2018-06-08 08:04:29 +08:00
|
|
|
static vm_fault_t dax_fault_return(int error)
|
2016-10-19 20:34:31 +08:00
|
|
|
{
|
|
|
|
if (error == 0)
|
|
|
|
return VM_FAULT_NOPAGE;
|
2019-01-05 03:24:11 +08:00
|
|
|
return vmf_error(error);
|
2016-10-19 20:34:31 +08:00
|
|
|
}
|
|
|
|
|
2017-11-14 08:38:44 +08:00
|
|
|
/*
|
|
|
|
* MAP_SYNC on a dax mapping guarantees dirty metadata is
|
|
|
|
* flushed on write-faults (non-cow), but not read-faults.
|
|
|
|
*/
|
|
|
|
static bool dax_fault_is_synchronous(unsigned long flags,
|
2021-08-11 09:33:15 +08:00
|
|
|
struct vm_area_struct *vma, const struct iomap *iomap)
|
2017-11-14 08:38:44 +08:00
|
|
|
{
|
|
|
|
return (flags & IOMAP_WRITE) && (vma->vm_flags & VM_SYNC)
|
|
|
|
&& (iomap->flags & IOMAP_F_DIRTY);
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
/*
|
|
|
|
* When handling a synchronous page fault and the inode need a fsync, we can
|
|
|
|
* insert the PTE/PMD into page tables only after that fsync happened. Skip
|
|
|
|
* insertion for now and return the pfn so that caller can insert it after the
|
|
|
|
* fsync is done.
|
|
|
|
*/
|
|
|
|
static vm_fault_t dax_fault_synchronous_pfnp(pfn_t *pfnp, pfn_t pfn)
|
|
|
|
{
|
|
|
|
if (WARN_ON_ONCE(!pfnp))
|
|
|
|
return VM_FAULT_SIGBUS;
|
|
|
|
*pfnp = pfn;
|
|
|
|
return VM_FAULT_NEEDDSYNC;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
static vm_fault_t dax_fault_cow_page(struct vm_fault *vmf,
|
|
|
|
const struct iomap_iter *iter)
|
2021-08-11 09:33:14 +08:00
|
|
|
{
|
|
|
|
vm_fault_t ret;
|
|
|
|
int error = 0;
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
switch (iter->iomap.type) {
|
2021-08-11 09:33:14 +08:00
|
|
|
case IOMAP_HOLE:
|
|
|
|
case IOMAP_UNWRITTEN:
|
2021-11-29 18:21:47 +08:00
|
|
|
clear_user_highpage(vmf->cow_page, vmf->address);
|
2021-08-11 09:33:14 +08:00
|
|
|
break;
|
|
|
|
case IOMAP_MAPPED:
|
2021-11-29 18:21:47 +08:00
|
|
|
error = copy_cow_page_dax(vmf, iter);
|
2021-08-11 09:33:14 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
error = -EIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
return dax_fault_return(error);
|
|
|
|
|
|
|
|
__SetPageUptodate(vmf->cow_page);
|
|
|
|
ret = finish_fault(vmf);
|
|
|
|
if (!ret)
|
|
|
|
return VM_FAULT_DONE_COW;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
/**
|
2021-08-11 09:33:15 +08:00
|
|
|
* dax_fault_iter - Common actor to handle pfn insertion in PTE/PMD fault.
|
2021-08-11 09:33:15 +08:00
|
|
|
* @vmf: vm fault instance
|
2021-08-11 09:33:15 +08:00
|
|
|
* @iter: iomap iter
|
2021-08-11 09:33:15 +08:00
|
|
|
* @pfnp: pfn to be returned
|
|
|
|
* @xas: the dax mapping tree of a file
|
|
|
|
* @entry: an unlocked dax entry to be inserted
|
|
|
|
* @pmd: distinguish whether it is a pmd fault
|
|
|
|
*/
|
2021-08-11 09:33:15 +08:00
|
|
|
static vm_fault_t dax_fault_iter(struct vm_fault *vmf,
|
|
|
|
const struct iomap_iter *iter, pfn_t *pfnp,
|
|
|
|
struct xa_state *xas, void **entry, bool pmd)
|
2021-08-11 09:33:15 +08:00
|
|
|
{
|
|
|
|
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
|
2021-08-11 09:33:15 +08:00
|
|
|
const struct iomap *iomap = &iter->iomap;
|
2021-08-11 09:33:15 +08:00
|
|
|
size_t size = pmd ? PMD_SIZE : PAGE_SIZE;
|
|
|
|
loff_t pos = (loff_t)xas->xa_index << PAGE_SHIFT;
|
|
|
|
bool write = vmf->flags & FAULT_FLAG_WRITE;
|
2021-08-11 09:33:15 +08:00
|
|
|
bool sync = dax_fault_is_synchronous(iter->flags, vmf->vma, iomap);
|
2021-08-11 09:33:15 +08:00
|
|
|
unsigned long entry_flags = pmd ? DAX_PMD : 0;
|
|
|
|
int err = 0;
|
|
|
|
pfn_t pfn;
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
if (!pmd && vmf->cow_page)
|
|
|
|
return dax_fault_cow_page(vmf, iter);
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
/* if we are reading UNWRITTEN and HOLE, return a hole. */
|
|
|
|
if (!write &&
|
|
|
|
(iomap->type == IOMAP_UNWRITTEN || iomap->type == IOMAP_HOLE)) {
|
|
|
|
if (!pmd)
|
|
|
|
return dax_load_hole(xas, mapping, entry, vmf);
|
|
|
|
return dax_pmd_load_hole(xas, vmf, iomap, entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (iomap->type != IOMAP_MAPPED) {
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return pmd ? VM_FAULT_FALLBACK : VM_FAULT_SIGBUS;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
err = dax_iomap_pfn(&iter->iomap, pos, size, &pfn);
|
2021-08-11 09:33:15 +08:00
|
|
|
if (err)
|
|
|
|
return pmd ? VM_FAULT_FALLBACK : dax_fault_return(err);
|
|
|
|
|
|
|
|
*entry = dax_insert_entry(xas, mapping, vmf, *entry, pfn, entry_flags,
|
|
|
|
write && !sync);
|
|
|
|
|
|
|
|
if (sync)
|
|
|
|
return dax_fault_synchronous_pfnp(pfnp, pfn);
|
|
|
|
|
|
|
|
/* insert PMD pfn */
|
|
|
|
if (pmd)
|
|
|
|
return vmf_insert_pfn_pmd(vmf, pfn, write);
|
|
|
|
|
|
|
|
/* insert PTE pfn */
|
|
|
|
if (write)
|
|
|
|
return vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
|
|
|
|
return vmf_insert_mixed(vmf->vma, vmf->address, pfn);
|
|
|
|
}
|
|
|
|
|
2018-06-08 08:04:29 +08:00
|
|
|
static vm_fault_t dax_iomap_pte_fault(struct vm_fault *vmf, pfn_t *pfnp,
|
2018-01-08 05:38:43 +08:00
|
|
|
int *iomap_errp, const struct iomap_ops *ops)
|
2016-09-19 09:24:50 +08:00
|
|
|
{
|
2021-08-11 09:33:15 +08:00
|
|
|
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
|
2018-03-30 10:58:27 +08:00
|
|
|
XA_STATE(xas, &mapping->i_pages, vmf->pgoff);
|
2021-08-11 09:33:15 +08:00
|
|
|
struct iomap_iter iter = {
|
|
|
|
.inode = mapping->host,
|
|
|
|
.pos = (loff_t)vmf->pgoff << PAGE_SHIFT,
|
|
|
|
.len = PAGE_SIZE,
|
2021-11-29 18:21:58 +08:00
|
|
|
.flags = IOMAP_DAX | IOMAP_FAULT,
|
2021-08-11 09:33:15 +08:00
|
|
|
};
|
2018-06-08 08:04:29 +08:00
|
|
|
vm_fault_t ret = 0;
|
2016-09-19 09:24:50 +08:00
|
|
|
void *entry;
|
2021-08-11 09:33:15 +08:00
|
|
|
int error;
|
2016-09-19 09:24:50 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
trace_dax_pte_fault(iter.inode, vmf, ret);
|
2016-09-19 09:24:50 +08:00
|
|
|
/*
|
|
|
|
* Check whether offset isn't beyond end of file now. Caller is supposed
|
|
|
|
* to hold locks serializing us with truncate / punch hole so this is
|
|
|
|
* a reliable test.
|
|
|
|
*/
|
2021-08-11 09:33:15 +08:00
|
|
|
if (iter.pos >= i_size_read(iter.inode)) {
|
2018-06-08 08:04:29 +08:00
|
|
|
ret = VM_FAULT_SIGBUS;
|
dax: add tracepoints to dax_iomap_pte_fault()
Patch series "second round of tracepoints for DAX".
This second round of DAX tracepoint patches adds tracing to the PTE
fault path (dax_iomap_pte_fault(), dax_pfn_mkwrite(), dax_load_hole(),
dax_insert_mapping()) and to the writeback path
(dax_writeback_mapping_range(), dax_writeback_one()).
The purpose of this tracing is to give us a high level view of what DAX
is doing, whether faults are being serviced by PMDs or PTEs, and by real
storage or by zero pages covering holes.
I do have some patches nearly ready which also add tracing to
grab_mapping_entry() and dax_insert_mapping_entry(). These are more
targeted at logging how we are interacting with the radix tree, how we
use empty entries for locking, whether we "downgrade" huge zero pages to
4k PTE sized allocations, etc. In the end it seemed to me that this
might be too detailed to have as constantly present tracepoints, but if
anyone sees value in having tracepoints like this in the DAX code
permanently (Jan?), please let me know and I'll add those last two
patches.
All these tracepoints were done to be consistent with the style of the
XFS tracepoints and with the existing DAX PMD tracepoints.
This patch (of 6):
Add tracepoints to dax_iomap_pte_fault(), following the same logging
conventions as the rest of DAX.
Here is an example fault that initially tries to be serviced by the PMD
fault handler but which falls back to PTEs because the VMA isn't large
enough to hold a PMD:
small-1086 [005] ....
71.140014: xfs_filemap_huge_fault: dev 259:0 ino 0x1003
small-1086 [005] ....
71.140027: dax_pmd_fault: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10420000 vm_start 0x10200000 vm_end 0x10500000 pgoff 0x220 max_pgoff 0x1400
small-1086 [005] ....
71.140028: dax_pmd_fault_done: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10420000 vm_start 0x10200000 vm_end 0x10500000 pgoff 0x220 max_pgoff 0x1400 FALLBACK
small-1086 [005] ....
71.140035: dax_pte_fault: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10420000 pgoff 0x220
small-1086 [005] ....
71.140396: dax_pte_fault_done: dev 259:0 ino 0x1003 shared WRITE|ALLOW_RETRY|KILLABLE|USER address 0x10420000 pgoff 0x220 MAJOR|NOPAGE
Link: http://lkml.kernel.org/r/20170221195116.13278-2-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-05-09 07:00:00 +08:00
|
|
|
goto out;
|
|
|
|
}
|
2016-09-19 09:24:50 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
if ((vmf->flags & FAULT_FLAG_WRITE) && !vmf->cow_page)
|
|
|
|
iter.flags |= IOMAP_WRITE;
|
2016-09-19 09:24:50 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
entry = grab_mapping_entry(&xas, mapping, 0);
|
|
|
|
if (xa_is_internal(entry)) {
|
|
|
|
ret = xa_to_internal(entry);
|
2017-05-13 06:46:57 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-06-03 05:46:37 +08:00
|
|
|
/*
|
|
|
|
* It is possible, particularly with mixed reads & writes to private
|
|
|
|
* mappings, that we have raced with a PMD fault that overlaps with
|
|
|
|
* the PTE we need to set up. If so just return and the fault will be
|
|
|
|
* retried.
|
|
|
|
*/
|
|
|
|
if (pmd_trans_huge(*vmf->pmd) || pmd_devmap(*vmf->pmd)) {
|
2018-06-08 08:04:29 +08:00
|
|
|
ret = VM_FAULT_NOPAGE;
|
2017-06-03 05:46:37 +08:00
|
|
|
goto unlock_entry;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
while ((error = iomap_iter(&iter, ops)) > 0) {
|
|
|
|
if (WARN_ON_ONCE(iomap_length(&iter) < PAGE_SIZE)) {
|
|
|
|
iter.processed = -EIO; /* fs corruption? */
|
|
|
|
continue;
|
2016-09-19 09:24:50 +08:00
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
ret = dax_fault_iter(vmf, &iter, pfnp, &xas, &entry, false);
|
|
|
|
if (ret != VM_FAULT_SIGBUS &&
|
|
|
|
(iter.iomap.flags & IOMAP_F_NEW)) {
|
2016-09-19 09:24:50 +08:00
|
|
|
count_vm_event(PGMAJFAULT);
|
2021-08-11 09:33:15 +08:00
|
|
|
count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
|
|
|
|
ret |= VM_FAULT_MAJOR;
|
2016-09-19 09:24:50 +08:00
|
|
|
}
|
2017-11-01 23:36:36 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
if (!(ret & VM_FAULT_ERROR))
|
|
|
|
iter.processed = PAGE_SIZE;
|
2016-09-19 09:24:50 +08:00
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
if (iomap_errp)
|
|
|
|
*iomap_errp = error;
|
|
|
|
if (!ret && error)
|
|
|
|
ret = dax_fault_return(error);
|
2016-10-19 20:34:31 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
unlock_entry:
|
2018-03-30 10:58:27 +08:00
|
|
|
dax_unlock_entry(&xas, entry);
|
2021-08-11 09:33:15 +08:00
|
|
|
out:
|
2021-08-11 09:33:15 +08:00
|
|
|
trace_dax_pte_fault_done(iter.inode, vmf, ret);
|
|
|
|
return ret;
|
2016-09-19 09:24:50 +08:00
|
|
|
}
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_FS_DAX_PMD
|
2021-08-11 09:33:14 +08:00
|
|
|
static bool dax_fault_check_fallback(struct vm_fault *vmf, struct xa_state *xas,
|
|
|
|
pgoff_t max_pgoff)
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
{
|
2017-02-23 07:40:06 +08:00
|
|
|
unsigned long pmd_addr = vmf->address & PMD_MASK;
|
2021-08-11 09:33:14 +08:00
|
|
|
bool write = vmf->flags & FAULT_FLAG_WRITE;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
/*
|
|
|
|
* Make sure that the faulting address's PMD offset (color) matches
|
|
|
|
* the PMD offset from the start of the file. This is necessary so
|
|
|
|
* that a PMD range in the page table overlaps exactly with a PMD
|
|
|
|
* range in the page cache.
|
|
|
|
*/
|
|
|
|
if ((vmf->pgoff & PG_PMD_COLOUR) !=
|
|
|
|
((vmf->address >> PAGE_SHIFT) & PG_PMD_COLOUR))
|
|
|
|
return true;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
/* Fall back to PTEs if we're going to COW */
|
|
|
|
if (write && !(vmf->vma->vm_flags & VM_SHARED))
|
|
|
|
return true;
|
2019-03-09 20:07:21 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
/* If the PMD would extend outside the VMA */
|
|
|
|
if (pmd_addr < vmf->vma->vm_start)
|
|
|
|
return true;
|
|
|
|
if ((pmd_addr + PMD_SIZE) > vmf->vma->vm_end)
|
|
|
|
return true;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
/* If the PMD would extend beyond the file size */
|
|
|
|
if ((xas->xa_index | PG_PMD_COLOUR) >= max_pgoff)
|
|
|
|
return true;
|
2017-02-23 07:39:57 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
return false;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
}
|
|
|
|
|
2018-06-08 08:04:29 +08:00
|
|
|
static vm_fault_t dax_iomap_pmd_fault(struct vm_fault *vmf, pfn_t *pfnp,
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
const struct iomap_ops *ops)
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
{
|
2021-08-11 09:33:15 +08:00
|
|
|
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
|
2018-03-30 10:58:27 +08:00
|
|
|
XA_STATE_ORDER(xas, &mapping->i_pages, vmf->pgoff, PMD_ORDER);
|
2021-08-11 09:33:15 +08:00
|
|
|
struct iomap_iter iter = {
|
|
|
|
.inode = mapping->host,
|
|
|
|
.len = PMD_SIZE,
|
2021-11-29 18:21:58 +08:00
|
|
|
.flags = IOMAP_DAX | IOMAP_FAULT,
|
2021-08-11 09:33:15 +08:00
|
|
|
};
|
2021-08-11 09:33:15 +08:00
|
|
|
vm_fault_t ret = VM_FAULT_FALLBACK;
|
2018-03-30 10:58:27 +08:00
|
|
|
pgoff_t max_pgoff;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
void *entry;
|
|
|
|
int error;
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
if (vmf->flags & FAULT_FLAG_WRITE)
|
|
|
|
iter.flags |= IOMAP_WRITE;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2017-02-23 07:39:50 +08:00
|
|
|
/*
|
|
|
|
* Check whether offset isn't beyond end of file now. Caller is
|
|
|
|
* supposed to hold locks serializing us with truncate / punch hole so
|
|
|
|
* this is a reliable test.
|
|
|
|
*/
|
2021-08-11 09:33:15 +08:00
|
|
|
max_pgoff = DIV_ROUND_UP(i_size_read(iter.inode), PAGE_SIZE);
|
dax: fix deadlock due to misaligned PMD faults
In DAX there are two separate places where the 2MiB range of a PMD is
defined.
The first is in the page tables, where a PMD mapping inserted for a
given address spans from (vmf->address & PMD_MASK) to ((vmf->address &
PMD_MASK) + PMD_SIZE - 1). That is, from the 2MiB boundary below the
address to the 2MiB boundary above the address.
So, for example, a fault at address 3MiB (0x30 0000) falls within the
PMD that ranges from 2MiB (0x20 0000) to 4MiB (0x40 0000).
The second PMD range is in the mapping->page_tree, where a given file
offset is covered by a radix tree entry that spans from one 2MiB aligned
file offset to another 2MiB aligned file offset.
So, for example, the file offset for 3MiB (pgoff 768) falls within the
PMD range for the order 9 radix tree entry that ranges from 2MiB (pgoff
512) to 4MiB (pgoff 1024).
This system works so long as the addresses and file offsets for a given
mapping both have the same offsets relative to the start of each PMD.
Consider the case where the starting address for a given file isn't 2MiB
aligned - say our faulting address is 3 MiB (0x30 0000), but that
corresponds to the beginning of our file (pgoff 0). Now all the PMDs in
the mapping are misaligned so that the 2MiB range defined in the page
tables never matches up with the 2MiB range defined in the radix tree.
The current code notices this case for DAX faults to storage with the
following test in dax_pmd_insert_mapping():
if (pfn_t_to_pfn(pfn) & PG_PMD_COLOUR)
goto unlock_fallback;
This test makes sure that the pfn we get from the driver is 2MiB
aligned, and relies on the assumption that the 2MiB alignment of the pfn
we get back from the driver matches the 2MiB alignment of the faulting
address.
However, faults to holes were not checked and we could hit the problem
described above.
This was reported in response to the NVML nvml/src/test/pmempool_sync
TEST5:
$ cd nvml/src/test/pmempool_sync
$ make TEST5
You can grab NVML here:
https://github.com/pmem/nvml/
The dmesg warning you see when you hit this error is:
WARNING: CPU: 13 PID: 2900 at fs/dax.c:641 dax_insert_mapping_entry+0x2df/0x310
Where we notice in dax_insert_mapping_entry() that the radix tree entry
we are about to replace doesn't match the locked entry that we had
previously inserted into the tree. This happens because the initial
insertion was done in grab_mapping_entry() using a pgoff calculated from
the faulting address (vmf->address), and the replacement in
dax_pmd_load_hole() => dax_insert_mapping_entry() is done using
vmf->pgoff.
In our failure case those two page offsets (one calculated from
vmf->address, one using vmf->pgoff) point to different order 9 radix
tree entries.
This failure case can result in a deadlock because the radix tree unlock
also happens on the pgoff calculated from vmf->address. This means that
the locked radix tree entry that we swapped in to the tree in
dax_insert_mapping_entry() using vmf->pgoff is never unlocked, so all
future faults to that 2MiB range will block forever.
Fix this by validating that the faulting address's PMD offset matches
the PMD offset from the start of the file. This check is done at the
very beginning of the fault and covers faults that would have mapped to
storage as well as faults to holes. I left the COLOUR check in
dax_pmd_insert_mapping() in place in case we ever hit the insanity
condition where the alignment of the pfn we get from the driver doesn't
match the alignment of the userspace address.
Link: http://lkml.kernel.org/r/20170822222436.18926-1-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: "Slusarz, Marcin" <marcin.slusarz@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-08-26 06:55:36 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
trace_dax_pmd_fault(iter.inode, vmf, max_pgoff, 0);
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2018-03-30 10:58:27 +08:00
|
|
|
if (xas.xa_index >= max_pgoff) {
|
2021-08-11 09:33:15 +08:00
|
|
|
ret = VM_FAULT_SIGBUS;
|
2017-02-23 07:39:50 +08:00
|
|
|
goto out;
|
|
|
|
}
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
|
2021-08-11 09:33:14 +08:00
|
|
|
if (dax_fault_check_fallback(vmf, &xas, max_pgoff))
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
goto fallback;
|
|
|
|
|
2017-05-13 06:47:00 +08:00
|
|
|
/*
|
2018-03-30 10:58:27 +08:00
|
|
|
* grab_mapping_entry() will make sure we get an empty PMD entry,
|
|
|
|
* a zero PMD entry or a DAX PMD. If it can't (because a PTE
|
|
|
|
* entry is already in the array, for instance), it will return
|
|
|
|
* VM_FAULT_FALLBACK.
|
2017-05-13 06:47:00 +08:00
|
|
|
*/
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = grab_mapping_entry(&xas, mapping, PMD_ORDER);
|
2018-03-30 10:58:27 +08:00
|
|
|
if (xa_is_internal(entry)) {
|
2021-08-11 09:33:15 +08:00
|
|
|
ret = xa_to_internal(entry);
|
2017-05-13 06:47:00 +08:00
|
|
|
goto fallback;
|
2018-03-30 10:58:27 +08:00
|
|
|
}
|
2017-05-13 06:47:00 +08:00
|
|
|
|
2017-06-03 05:46:37 +08:00
|
|
|
/*
|
|
|
|
* It is possible, particularly with mixed reads & writes to private
|
|
|
|
* mappings, that we have raced with a PTE fault that overlaps with
|
|
|
|
* the PMD we need to set up. If so just return and the fault will be
|
|
|
|
* retried.
|
|
|
|
*/
|
|
|
|
if (!pmd_none(*vmf->pmd) && !pmd_trans_huge(*vmf->pmd) &&
|
|
|
|
!pmd_devmap(*vmf->pmd)) {
|
2021-08-11 09:33:15 +08:00
|
|
|
ret = 0;
|
2017-06-03 05:46:37 +08:00
|
|
|
goto unlock_entry;
|
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
iter.pos = (loff_t)xas.xa_index << PAGE_SHIFT;
|
|
|
|
while ((error = iomap_iter(&iter, ops)) > 0) {
|
|
|
|
if (iomap_length(&iter) < PMD_SIZE)
|
|
|
|
continue; /* actually breaks out of the loop */
|
2017-11-01 23:36:42 +08:00
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
ret = dax_fault_iter(vmf, &iter, pfnp, &xas, &entry, true);
|
|
|
|
if (ret != VM_FAULT_FALLBACK)
|
|
|
|
iter.processed = PMD_SIZE;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
}
|
|
|
|
|
2021-08-11 09:33:15 +08:00
|
|
|
unlock_entry:
|
2018-03-30 10:58:27 +08:00
|
|
|
dax_unlock_entry(&xas, entry);
|
2021-08-11 09:33:15 +08:00
|
|
|
fallback:
|
|
|
|
if (ret == VM_FAULT_FALLBACK) {
|
2021-08-11 09:33:15 +08:00
|
|
|
split_huge_pmd(vmf->vma, vmf->pmd, vmf->address);
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
count_vm_event(THP_FAULT_FALLBACK);
|
|
|
|
}
|
2017-02-23 07:39:50 +08:00
|
|
|
out:
|
2021-08-11 09:33:15 +08:00
|
|
|
trace_dax_pmd_fault_done(iter.inode, vmf, max_pgoff, ret);
|
2021-08-11 09:33:15 +08:00
|
|
|
return ret;
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
}
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
#else
|
2018-06-08 08:04:29 +08:00
|
|
|
static vm_fault_t dax_iomap_pmd_fault(struct vm_fault *vmf, pfn_t *pfnp,
|
2017-02-28 06:26:44 +08:00
|
|
|
const struct iomap_ops *ops)
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
{
|
|
|
|
return VM_FAULT_FALLBACK;
|
|
|
|
}
|
dax: add struct iomap based DAX PMD support
DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking. This patch allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled using the new struct
iomap based fault handlers.
There are currently three types of DAX 4k entries: 4k zero pages, 4k DAX
mappings that have an associated block allocation, and 4k DAX empty
entries. The empty entries exist to provide locking for the duration of a
given page fault.
This patch adds three equivalent 2MiB DAX entries: Huge Zero Page (HZP)
entries, PMD DAX entries that have associated block allocations, and 2 MiB
DAX empty entries.
Unlike the 4k case where we insert a struct page* into the radix tree for
4k zero pages, for HZP we insert a DAX exceptional entry with the new
RADIX_DAX_HZP flag set. This is because we use a single 2 MiB zero page in
every 2MiB hole mapping, and it doesn't make sense to have that same struct
page* with multiple entries in multiple trees. This would cause contention
on the single page lock for the one Huge Zero Page, and it would break the
page->index and page->mapping associations that are assumed to be valid in
many other places in the kernel.
One difficult use case is when one thread is trying to use 4k entries in
radix tree for a given offset, and another thread is using 2 MiB entries
for that same offset. The current code handles this by making the 2 MiB
user fall back to 4k entries for most cases. This was done because it is
the simplest solution, and because the use of 2MiB pages is already
opportunistic.
If we were to try to upgrade from 4k pages to 2MiB pages for a given range,
we run into the problem of how we lock out 4k page faults for the entire
2MiB range while we clean out the radix tree so we can insert the 2MiB
entry. We can solve this problem if we need to, but I think that the cases
where both 2MiB entries and 4K entries are being used for the same range
will be rare enough and the gain small enough that it probably won't be
worth the complexity.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2016-11-08 08:34:45 +08:00
|
|
|
#endif /* CONFIG_FS_DAX_PMD */
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dax_iomap_fault - handle a page fault on a DAX file
|
|
|
|
* @vmf: The description of the fault
|
2017-11-01 23:36:38 +08:00
|
|
|
* @pe_size: Size of the page to fault in
|
2017-11-01 23:36:39 +08:00
|
|
|
* @pfnp: PFN to insert for synchronous faults if fsync is required
|
2018-01-08 05:38:43 +08:00
|
|
|
* @iomap_errp: Storage for detailed error code in case of error
|
2017-11-01 23:36:38 +08:00
|
|
|
* @ops: Iomap ops passed from the file system
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
*
|
|
|
|
* When a page fault occurs, filesystems may call this helper in
|
|
|
|
* their fault handler for DAX files. dax_iomap_fault() assumes the caller
|
|
|
|
* has done all the necessary locking for page fault to proceed
|
|
|
|
* successfully.
|
|
|
|
*/
|
2018-06-08 08:04:29 +08:00
|
|
|
vm_fault_t dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,
|
2018-01-08 05:38:43 +08:00
|
|
|
pfn_t *pfnp, int *iomap_errp, const struct iomap_ops *ops)
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
{
|
2017-02-25 06:57:08 +08:00
|
|
|
switch (pe_size) {
|
|
|
|
case PE_SIZE_PTE:
|
2018-01-08 05:38:43 +08:00
|
|
|
return dax_iomap_pte_fault(vmf, pfnp, iomap_errp, ops);
|
2017-02-25 06:57:08 +08:00
|
|
|
case PE_SIZE_PMD:
|
2017-11-01 23:36:39 +08:00
|
|
|
return dax_iomap_pmd_fault(vmf, pfnp, ops);
|
mm,fs,dax: change ->pmd_fault to ->huge_fault
Patch series "1G transparent hugepage support for device dax", v2.
The following series implements support for 1G trasparent hugepage on
x86 for device dax. The bulk of the code was written by Mathew Wilcox a
while back supporting transparent 1G hugepage for fs DAX. I have
forward ported the relevant bits to 4.10-rc. The current submission has
only the necessary code to support device DAX.
Comments from Dan Williams: So the motivation and intended user of this
functionality mirrors the motivation and users of 1GB page support in
hugetlbfs. Given expected capacities of persistent memory devices an
in-memory database may want to reduce tlb pressure beyond what they can
already achieve with 2MB mappings of a device-dax file. We have
customer feedback to that effect as Willy mentioned in his previous
version of these patches [1].
[1]: https://lkml.org/lkml/2016/1/31/52
Comments from Nilesh @ Oracle:
There are applications which have a process model; and if you assume
10,000 processes attempting to mmap all the 6TB memory available on a
server; we are looking at the following:
processes : 10,000
memory : 6TB
pte @ 4k page size: 8 bytes / 4K of memory * #processes = 6TB / 4k * 8 * 10000 = 1.5GB * 80000 = 120,000GB
pmd @ 2M page size: 120,000 / 512 = ~240GB
pud @ 1G page size: 240GB / 512 = ~480MB
As you can see with 2M pages, this system will use up an exorbitant
amount of DRAM to hold the page tables; but the 1G pages finally brings
it down to a reasonable level. Memory sizes will keep increasing; so
this number will keep increasing.
An argument can be made to convert the applications from process model
to thread model, but in the real world that may not be always practical.
Hopefully this helps explain the use case where this is valuable.
This patch (of 3):
In preparation for adding the ability to handle PUD pages, convert
vm_operations_struct.pmd_fault to vm_operations_struct.huge_fault. The
vm_fault structure is extended to include a union of the different page
table pointers that may be needed, and three flag bits are reserved to
indicate which type of pointer is in the union.
[ross.zwisler@linux.intel.com: remove unused function ext4_dax_huge_fault()]
Link: http://lkml.kernel.org/r/1485813172-7284-1-git-send-email-ross.zwisler@linux.intel.com
[dave.jiang@intel.com: clear PMD or PUD size flags when in fall through path]
Link: http://lkml.kernel.org/r/148589842696.5820.16078080610311444794.stgit@djiang5-desk3.ch.intel.com
Link: http://lkml.kernel.org/r/148545058784.17912.6353162518188733642.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jan Kara <jack@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Nilesh Choudhury <nilesh.choudhury@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-25 06:56:59 +08:00
|
|
|
default:
|
|
|
|
return VM_FAULT_FALLBACK;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dax_iomap_fault);
|
2017-11-01 23:36:43 +08:00
|
|
|
|
2018-03-28 01:39:38 +08:00
|
|
|
/*
|
2017-11-01 23:36:43 +08:00
|
|
|
* dax_insert_pfn_mkwrite - insert PTE or PMD entry into page tables
|
|
|
|
* @vmf: The description of the fault
|
|
|
|
* @pfn: PFN to insert
|
2018-03-28 23:48:03 +08:00
|
|
|
* @order: Order of entry to insert.
|
2017-11-01 23:36:43 +08:00
|
|
|
*
|
2018-03-28 01:39:38 +08:00
|
|
|
* This function inserts a writeable PTE or PMD entry into the page tables
|
|
|
|
* for an mmaped DAX file. It also marks the page cache entry as dirty.
|
2017-11-01 23:36:43 +08:00
|
|
|
*/
|
2018-03-28 23:48:03 +08:00
|
|
|
static vm_fault_t
|
|
|
|
dax_insert_pfn_mkwrite(struct vm_fault *vmf, pfn_t pfn, unsigned int order)
|
2017-11-01 23:36:43 +08:00
|
|
|
{
|
|
|
|
struct address_space *mapping = vmf->vma->vm_file->f_mapping;
|
2018-03-28 23:48:03 +08:00
|
|
|
XA_STATE_ORDER(xas, &mapping->i_pages, vmf->pgoff, order);
|
|
|
|
void *entry;
|
2018-06-08 08:04:29 +08:00
|
|
|
vm_fault_t ret;
|
2017-11-01 23:36:43 +08:00
|
|
|
|
2018-03-28 23:48:03 +08:00
|
|
|
xas_lock_irq(&xas);
|
2019-07-04 11:21:25 +08:00
|
|
|
entry = get_unlocked_entry(&xas, order);
|
2017-11-01 23:36:43 +08:00
|
|
|
/* Did we race with someone splitting entry or so? */
|
2019-07-04 11:21:25 +08:00
|
|
|
if (!entry || dax_is_conflict(entry) ||
|
|
|
|
(order == 0 && !dax_is_pte_entry(entry))) {
|
2021-04-29 03:03:13 +08:00
|
|
|
put_unlocked_entry(&xas, entry, WAKE_NEXT);
|
2018-03-28 23:48:03 +08:00
|
|
|
xas_unlock_irq(&xas);
|
2017-11-01 23:36:43 +08:00
|
|
|
trace_dax_insert_pfn_mkwrite_no_entry(mapping->host, vmf,
|
|
|
|
VM_FAULT_NOPAGE);
|
|
|
|
return VM_FAULT_NOPAGE;
|
|
|
|
}
|
2018-03-28 23:48:03 +08:00
|
|
|
xas_set_mark(&xas, PAGECACHE_TAG_DIRTY);
|
|
|
|
dax_lock_entry(&xas, entry);
|
|
|
|
xas_unlock_irq(&xas);
|
|
|
|
if (order == 0)
|
2018-06-08 08:04:29 +08:00
|
|
|
ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address, pfn);
|
2017-11-01 23:36:43 +08:00
|
|
|
#ifdef CONFIG_FS_DAX_PMD
|
2018-03-28 23:48:03 +08:00
|
|
|
else if (order == PMD_ORDER)
|
2019-05-14 08:15:33 +08:00
|
|
|
ret = vmf_insert_pfn_pmd(vmf, pfn, FAULT_FLAG_WRITE);
|
2017-11-01 23:36:43 +08:00
|
|
|
#endif
|
2018-03-28 23:48:03 +08:00
|
|
|
else
|
2018-06-08 08:04:29 +08:00
|
|
|
ret = VM_FAULT_FALLBACK;
|
2018-03-28 23:48:03 +08:00
|
|
|
dax_unlock_entry(&xas, entry);
|
2018-06-08 08:04:29 +08:00
|
|
|
trace_dax_insert_pfn_mkwrite(mapping->host, vmf, ret);
|
|
|
|
return ret;
|
2017-11-01 23:36:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dax_finish_sync_fault - finish synchronous page fault
|
|
|
|
* @vmf: The description of the fault
|
|
|
|
* @pe_size: Size of entry to be inserted
|
|
|
|
* @pfn: PFN to insert
|
|
|
|
*
|
|
|
|
* This function ensures that the file range touched by the page fault is
|
|
|
|
* stored persistently on the media and handles inserting of appropriate page
|
|
|
|
* table entry.
|
|
|
|
*/
|
2018-06-08 08:04:29 +08:00
|
|
|
vm_fault_t dax_finish_sync_fault(struct vm_fault *vmf,
|
|
|
|
enum page_entry_size pe_size, pfn_t pfn)
|
2017-11-01 23:36:43 +08:00
|
|
|
{
|
|
|
|
int err;
|
|
|
|
loff_t start = ((loff_t)vmf->pgoff) << PAGE_SHIFT;
|
2018-03-28 23:48:03 +08:00
|
|
|
unsigned int order = pe_order(pe_size);
|
|
|
|
size_t len = PAGE_SIZE << order;
|
2017-11-01 23:36:43 +08:00
|
|
|
|
|
|
|
err = vfs_fsync_range(vmf->vma->vm_file, start, start + len - 1, 1);
|
|
|
|
if (err)
|
|
|
|
return VM_FAULT_SIGBUS;
|
2018-03-28 23:48:03 +08:00
|
|
|
return dax_insert_pfn_mkwrite(vmf, pfn, order);
|
2017-11-01 23:36:43 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dax_finish_sync_fault);
|