On 5/18/21 8:56 PM, Jane Chu wrote:
> On 5/18/2021 10:27 AM, Joao Martins wrote:
>
>> On 5/5/21 11:36 PM, Joao Martins wrote:
>>> On 5/5/21 11:20 PM, Dan Williams wrote:
>>>> On Wed, May 5, 2021 at 12:50 PM Joao Martins
>>>> wrote:
>>>&
On 5/5/21 11:36 PM, Joao Martins wrote:
> On 5/5/21 11:20 PM, Dan Williams wrote:
>> On Wed, May 5, 2021 at 12:50 PM Joao Martins
>> wrote:
>>> On 5/5/21 7:44 PM, Dan Williams wrote:
>>>> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
>>>> wrot
On 5/10/21 8:19 PM, Dan Williams wrote:
> On Thu, May 6, 2021 at 4:02 AM Joao Martins wrote:
> [..]
>>>> +static pte_t * __meminit vmemmap_lookup_address(unsigned long addr)
>>>
>>> I think this can be replaced with a call to follow_pte(_mm...).
>>>
&
On 5/6/21 11:27 AM, Joao Martins wrote:
> On 5/5/21 11:43 PM, Dan Williams wrote:
>> I suspect it's a good sign I'm only finding cosmetic and changelog
>> changes in the review...
>
> Hopefully it continues that way, but the meat of the series is located
> in patches 4,
On 5/6/21 12:43 PM, Matthew Wilcox wrote:
> On Thu, May 06, 2021 at 11:23:25AM +0100, Joao Martins wrote:
>>>> I think it is ok for dax/nvdimm to continue to maintain their align
>>>> value because it should be ok to have 4MB align if the device really
>>>&g
On 5/6/21 2:18 AM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> A compound pagemap is a dev_pagemap with @align > PAGE_SIZE and it
>> means that pages are mapped at a given huge page alignment and utilize
>> uses compound
gt; an idea of the impact and side effects of the change.
>
Fixed.
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>
> I would add a lead in phrase like: "In preparation for describing a
> memmap with compound pages, move the actual..."
On 5/6/21 12:14 AM, Dan Williams wrote:
> On Wed, May 5, 2021 at 3:38 PM Joao Martins wrote:
>>
>>
>>
>> On 5/5/21 11:34 PM, Dan Williams wrote:
>>> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
>>> wrote:
>>>>
>>&
On 5/6/21 9:05 AM, Aneesh Kumar K.V wrote:
>
>
> IIUC this series is about devdax namespace with aligh of 1G or 2M where we can
> save the vmmemap space by not allocating memory for tail struct pages?
>
Right.
It reuses base pages across the vmemmap, but for the base pages containing
only
On 5/6/21 12:03 AM, Dan Williams wrote:
> On Wed, May 5, 2021 at 3:36 PM Joao Martins wrote:
> [..]
>>> Ah yup, my eyes glazed over that. I think this is another place that
>>> benefits from a more specific name than "align". "pfns_per_compound"
>>
On 5/5/21 11:34 PM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> @altmap is stored in a dev_pagemap, but it will be repurposed for
>> hotplug memory for storing the memmap in the hotplugged memory[*] and
>> reusing the alt
On 5/5/21 11:20 PM, Dan Williams wrote:
> On Wed, May 5, 2021 at 12:50 PM Joao Martins
> wrote:
>> On 5/5/21 7:44 PM, Dan Williams wrote:
>>> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
>>> wrote:
>>>>
>>>> Add a new align property for
On 5/5/21 7:44 PM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> Add a new align property for struct dev_pagemap which specifies that a
>> pagemap is composed of a set of compound pages of size @align, instead
>> o
On 4/24/21 1:18 AM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> Move struct page init to an helper function __init_zone_device_page().
>
> Same sentence addition suggestion from the last patch to make this
> patch have some r
On 4/24/21 1:16 AM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> Split the utility function prep_compound_page() into head and tail
>> counterparts, and use them accordingly.
>
> To make this patch stand alone be
On 4/24/21 1:12 AM, Dan Williams wrote:
> On Thu, Mar 25, 2021 at 4:10 PM Joao Martins
> wrote:
>>
>> memory_failure_dev_pagemap() at the moment assumes base pages (e.g.
>> dax_lock_page()). For pagemap with compound pages fetch the
>> compound_head in case we a
On 3/24/21 7:00 PM, Joao Martins wrote:
> On 3/24/21 5:45 PM, Dan Williams wrote:
>> On Thu, Mar 18, 2021 at 3:02 AM Joao Martins
>> wrote:
>>> On 3/18/21 4:08 AM, Dan Williams wrote:
>>>> Now that device-dax and filesystem-dax are guaranteed to unmap all user
On 3/25/21 11:09 PM, Joao Martins wrote:
[...]
> Patch 11: Optimize grabbing page refcount changes given that we
> are working with compound pages i.e. we do 1 increment to the head
> page for a given set of N subpages compared as opposed to N individual writes.
> {get,pin}_use
_fast 2M pages) ~3.97 sec -> ~74 ms
Signed-off-by: Joao Martins
---
mm/gup.c | 52
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index b3e647c8b7ee..514f12157a0f 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -21
Split the utility function prep_compound_page() into head and tail
counterparts, and use them accordingly.
Signed-off-by: Joao Martins
---
mm/page_alloc.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
m RFC series from 190ms -> 80-120ms. Patches 2 and 3 are the new ones
as a result (Dan)
* Remove PGMAP_COMPOUND and use @align as the property to detect whether
or not to reuse vmemmap areas (Dan)
Thanks,
Joao
Joao Martins (11):
memory-failure: fetch compound_head after pgma
Move struct page init to an helper function __init_zone_device_page().
Signed-off-by: Joao Martins
---
mm/page_alloc.c | 74 +++--
1 file changed, 41 insertions(+), 33 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 43dd98446b0b
requiring 8 PMD page allocations we only need 2 (plus two base pages
allocated for head and tail areas for the first PMD). 2M pages still
require using base pages, though.
Signed-off-by: Joao Martins
---
include/linux/mm.h | 3 +-
mm/sparse-vmemmap.c | 79
considerably less
pages.
On setups with 128G NVDIMMs the initialization with DRAM stored struct pages
improves from ~268-358 ms to ~78-100 ms with 2M pages, and to less than
a 1msec with 1G pages.
Signed-off-by: Joao Martins
---
drivers/dax/device.c | 58
in which memmap metadata is created for and also to let sparse-vmemmap
fetch pgmap ranges to co-relate to a given section and pick whether to just
reuse tail pages from past onlined sections.
[*] https://lore.kernel.org/linux-mm/20210319092635.6214-1-osalva...@suse.de/
Signed-off-by: Joao Martins
memory_failure_dev_pagemap() to keep working.
Reported-by: Jane Chu
Signed-off-by: Joao Martins
---
mm/memory-failure.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 24210c9bd843..94240d772623 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
which have a fixed page
size, this creates an opportunity to optimize GUP and GUP-fast walkers,
treating it the same way as THP or hugetlb pages.
Signed-off-by: Joao Martins
---
include/linux/memremap.h | 13 +
mm/memremap.c| 8 ++--
mm/page_alloc.c | 24
Move the actual pte population logic into a separate function
vmemmap_populate_address() and have vmemmap_populate_basepages()
walk through all base pages it needs to populate.
Signed-off-by: Joao Martins
---
mm/sparse-vmemmap.c | 44 ++--
1 file changed
map it saves
4094 pages.
Altmap isn't supported yet, given various restrictions in altmap pfn
allocator, thus fallback to the already in use vmemmap_populate().
Signed-off-by: Joao Martins
---
include/linux/mm.h | 2 +-
mm/memremap.c | 1 +
mm/sparse-vmemmap.c |
ign or 262144 for a 1G @align.
Keep old behaviour with altmap given that it doesn't support reusal
of tail vmemmap areas.
Signed-off-by: Joao Martins
---
mm/page_alloc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3a77f9e43
On 3/24/21 5:45 PM, Dan Williams wrote:
> On Thu, Mar 18, 2021 at 3:02 AM Joao Martins
> wrote:
>> On 3/18/21 4:08 AM, Dan Williams wrote:
>>> Now that device-dax and filesystem-dax are guaranteed to unmap all user
>>> mappings of devmap / DAX pages before
On 3/18/21 4:08 AM, Dan Williams wrote:
> Now that device-dax and filesystem-dax are guaranteed to unmap all user
> mappings of devmap / DAX pages before tearing down the 'struct page'
> array, get_user_pages_fast() can rely on its traditional synchronization
> method "validate_pte(); get_page();
On 2/22/21 8:37 PM, Dan Williams wrote:
> On Mon, Feb 22, 2021 at 3:24 AM Joao Martins
> wrote:
>> On 2/20/21 1:43 AM, Dan Williams wrote:
>>> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard wrote:
>>>> On 12/8/20 9:28 AM, Joao Martins wrote:
>&
On 2/23/21 4:50 PM, Dan Williams wrote:
> On Tue, Feb 23, 2021 at 7:46 AM Joao Martins
> wrote:
>> On 2/22/21 8:37 PM, Dan Williams wrote:
>>> On Mon, Feb 22, 2021 at 3:24 AM Joao Martins
>>> wrote:
>>>> On 2/20/21 1:43 AM, Dan Williams wrote:
>>
On 2/23/21 4:44 PM, Dan Williams wrote:
> On Tue, Feb 23, 2021 at 8:30 AM Joao Martins
> wrote:
>>
>> On 2/20/21 1:18 AM, Dan Williams wrote:
>>> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins
>>> wrote:
>>>> Patch 6 - 8: Optimize grabbing/rel
On 2/20/21 1:18 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins wrote:
>> Patch 6 - 8: Optimize grabbing/release a page refcount changes given that we
>> are working with compound pages i.e. we do 1 increment/decrement to the head
>> page for a gi
On 2/22/21 10:40 PM, Dan Williams wrote:
> On Mon, Feb 22, 2021 at 3:42 AM Joao Martins
> wrote:
>> On 2/20/21 3:34 AM, Dan Williams wrote:
>>> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins
>>> wrote:
>>>> Sections are 128M (or bigger/smaller),
&
On 2/22/21 8:37 PM, Dan Williams wrote:
> On Mon, Feb 22, 2021 at 3:24 AM Joao Martins
> wrote:
>> On 2/20/21 1:43 AM, Dan Williams wrote:
>>> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard wrote:
>>>> On 12/8/20 9:28 AM, Joao Martins wrote:
>>>>
On 2/22/21 11:06 AM, Joao Martins wrote:
> On 2/20/21 1:18 AM, Dan Williams wrote:
>> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins
>> wrote:
>>>
>>> The link above describes it quite nicely, but the idea is to reuse tail
>>> page vmemmap areas, par
On 2/20/21 6:17 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:31 AM Joao Martins wrote:
>>
>> When PGMAP_COMPOUND is set, all pages are onlined at a given huge page
>> alignment and using compound pages to describe them as opposed to a
>> struct per 4K.
&
On 2/20/21 3:34 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins wrote:
>>
>> Introduce a new flag, MEMHP_REUSE_VMEMMAP, which signals that
>> struct pages are onlined with a given alignment, and should reuse the
>> tail pages vmemmap areas. On
On 2/20/21 1:49 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:31 AM Joao Martins wrote:
>>
>> Replace vmem_altmap with an vmem_context argument. That let us
>> express how the vmemmap is gonna be initialized e.g. passing
>> flags and a page size for reus
On 2/20/21 1:43 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:59 PM John Hubbard wrote:
>> On 12/8/20 9:28 AM, Joao Martins wrote:
>>> diff --git a/mm/memremap.c b/mm/memremap.c
>>> index 16b2fb482da1..287a24b7a65a 100644
>>> --- a/mm/memremap.c
>>&
On 2/20/21 1:24 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins wrote:
>>
>> Add a new flag for struct dev_pagemap which designates that a a pagemap
>> is described as a set of compound pages or in other words, that how
>> pages are grouped
On 2/20/21 1:18 AM, Dan Williams wrote:
> On Tue, Dec 8, 2020 at 9:32 AM Joao Martins wrote:
>>
>> The link above describes it quite nicely, but the idea is to reuse tail
>> page vmemmap areas, particular the area which only describes tail pages.
>> So a vmemmap pag
On 1/26/21 2:13 AM, Shiyang Ruan wrote:
> The return value of range_parse() indicates the size when it is
> positive. The error code should be negative.
>
> Signed-off-by: Shiyang Ruan
Reviewed-by: Joao Martins
Although, FWIW, there was another patch exactly like this a coupl
On 12/9/20 10:59 AM, Joao Martins wrote:
> On 12/8/20 7:29 PM, Jason Gunthorpe wrote:
>> On Tue, Dec 08, 2020 at 05:29:00PM +0000, Joao Martins wrote:
>>
>>> static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem,
>>> int dirty)
>>>
On 12/19/20 2:06 AM, John Hubbard wrote:
> On 12/17/20 12:05 PM, Jason Gunthorpe wrote:
>> On Thu, Dec 17, 2020 at 07:05:37PM +0000, Joao Martins wrote:
>>>> No reason not to fix set_page_dirty_lock() too while you are here.
>>>
>>> The wack of atomics y
. It also allows an userspace application to pick
it's own ranges, should it want to avoid relying on kernel's policy.
Signed-off-by: Joao Martins
---
daxctl/lib/libdaxctl.c | 27 +++
daxctl/lib/libdaxctl.sym | 1 +
daxctl/libdaxctl.h | 2 ++
3 files changed, 30
The test creates a multi-range device (4 mappings) using the
same setup as one of the tests. Afterwards we validate that
the size/nr-mappings are the same as the original test.
Signed-off-by: Joao Martins
---
test/daxctl-create.sh | 31 ++-
1 file changed, 30
;size":34359738368,
"target_node":0,
"align":1073741824,
"mode":"devdax",
"mappings":[
{
"page_offset":4194304,
"start":25769803776,
"end":42
Iterate over the device mappings and print @page_offset,
@start, @end and a computed size, but only if user
passes -M|--mappings to daxctl list as the output can
get verbose with a lot of mapping entries.
Signed-off-by: Joao Martins
---
Documentation/daxctl/daxctl-list.txt | 4 +++
daxctl
Add the following APIs to be able to iterate over a
dynamic device-dax mapping list, as well as fetching
each of the mapping attributes.
Signed-off-by: Joao Martins
---
daxctl/lib/libdaxctl-private.h | 8
daxctl/lib/libdaxctl.c | 91
-M and for --input
Joao Martins (5):
libdaxctl: add mapping iterator APIs
daxctl: include mappings when listing
libdaxctl: add daxctl_dev_set_mapping()
daxctl: allow creating devices from input json
daxctl/test: add a test for daxctl-create with input file
Documentation/daxctl/daxctl-cre
On 12/17/20 8:05 PM, Jason Gunthorpe wrote:
> On Thu, Dec 17, 2020 at 07:05:37PM +0000, Joao Martins wrote:
>>> No reason not to fix set_page_dirty_lock() too while you are here.
>>
>> The wack of atomics you mentioned earlier you referred to, I suppose it
>> ends bei
On 12/8/20 7:34 PM, Jason Gunthorpe wrote:
>> @@ -274,6 +291,7 @@ void unpin_user_pages_dirty_lock(struct page **pages,
>> unsigned long npages,
>> bool make_dirty)
>> {
>> unsigned long index;
>> +int refs = 1;
>>
>> /*
>> * TODO: this can be
On 12/16/20 11:42 PM, Dan Williams wrote:
> On Wed, Dec 16, 2020 at 2:54 PM Joao Martins
> wrote:
>> On 12/16/20 10:31 PM, Dan Williams wrote:
>>> On Wed, Dec 16, 2020 at 1:51 PM Joao Martins
>>> wrote:
>>>> On 12/16/20 6:42 PM, Verma, Vishal L wrot
On 12/16/20 10:31 PM, Dan Williams wrote:
> On Wed, Dec 16, 2020 at 1:51 PM Joao Martins
> wrote:
>>
>> On 12/16/20 6:42 PM, Verma, Vishal L wrote:
>>> On Wed, 2020-12-16 at 11:39 +, Joao Martins wrote:
>>>> On 7/16/20 7:46 PM, Joao Martins wrote:
&g
Add support for changing devices alignment.
On kernels that do not support per-device align sysfs property
we set it to 0.
Signed-off-by: Joao Martins
---
daxctl/lib/libdaxctl-private.h | 1 +
daxctl/lib/libdaxctl.c | 36
daxctl/lib/libdaxctl.sym
Add a test which uses the newly added --align property
which allows a device created with daxctl create-device
to select its page size. If the available size is bigger
than 1G then use 1G as page size, otherwise use 2M.
Signed-off-by: Joao Martins
---
test/daxctl-create.sh | 29
Allow changing devices alignment when creating
a new child device.
Signed-off-by: Joao Martins
---
Documentation/daxctl/daxctl-create-device.txt | 8
daxctl/device.c | 8
2 files changed, 16 insertions(+)
diff --git a/Documentation/daxctl/daxctl
Add an alignment option to reconfigure-device and use the newly added
libdaxctl API to set the alignment of the device prior to setting size.
Signed-off-by: Joao Martins
---
Documentation/daxctl/daxctl-reconfigure-device.txt | 12 +++
daxctl/device.c
Fetch device align and include it on listings.
Signed-off-by: Joao Martins
---
util/json.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/util/json.c b/util/json.c
index 77bd4781551d..357dff20d6be 100644
--- a/util/json.c
+++ b/util/json.c
@@ -455,7 +455,7 @@ struct
dax devices on kernels that don't support align;
* Adds a unit test for align;
* Remove the mapping part to a later series;
Joao Martins (5):
daxctl: add daxctl_dev_{get,set}_align()
util/json: Print device align
daxctl: add align support in reconfigure-device
daxctl: add align supp
On 12/16/20 6:42 PM, Verma, Vishal L wrote:
> On Wed, 2020-12-16 at 11:39 +0000, Joao Martins wrote:
>> On 7/16/20 7:46 PM, Joao Martins wrote:
>>> Hey,
>>>
>>> This series builds on top of this one[0] and does the following improvements
>>> to the S
On 12/16/20 7:13 PM, Dan Williams wrote:
> On Wed, Dec 16, 2020 at 3:41 AM Joao Martins
> wrote:
>>
>> On 7/16/20 7:46 PM, Joao Martins wrote:
>>> Hey,
>>>
>>> This series builds on top of this one[0] and does the following improvements
>>>
On 7/16/20 7:46 PM, Joao Martins wrote:
> Hey,
>
> This series builds on top of this one[0] and does the following improvements
> to the Soft-Reserved subdivision:
>
> 1) Support for {create,reconfigure}-device for selecting @align (hugepage
> size).
> Here we ad
On 12/16/20 10:25 AM, Verma, Vishal L wrote:
> On Thu, 2020-12-10 at 15:01 +0000, Joao Martins wrote:
>> On 7/21/20 5:49 PM, Joao Martins wrote:
>>> On 7/13/20 5:08 PM, Joao Martins wrote:
>>>> Add a couple tests which exercise the new sysfs based
>>>> i
On 12/9/20 6:14 PM, Matthew Wilcox wrote:
> On Wed, Dec 09, 2020 at 12:24:38PM -0400, Jason Gunthorpe wrote:
>> On Wed, Dec 09, 2020 at 04:02:05PM +0000, Joao Martins wrote:
>>
>>> Today (without the series) struct pages are not represented the way they
>>>
On 7/21/20 5:49 PM, Joao Martins wrote:
> On 7/13/20 5:08 PM, Joao Martins wrote:
>> Add a couple tests which exercise the new sysfs based
>> interface for Soft-Reserved regions (by EFI/HMAT, or
>> efi_fake_mem).
>>
>> The tests exercise the daxctl orchestr
On 12/9/20 4:24 PM, Jason Gunthorpe wrote:
> On Wed, Dec 09, 2020 at 04:02:05PM +0000, Joao Martins wrote:
>
>> Today (without the series) struct pages are not represented the way they
>> are expressed in the page tables, which is what I am hoping to fix in this
>>
On 12/9/20 3:15 PM, Jason Gunthorpe wrote:
> On Wed, Dec 09, 2020 at 11:05:39AM +0000, Joao Martins wrote:
>>> Why is all of this special? Any time we see a PMD/PGD/etc pointing to
>>> PFN we can apply this optimization. How come device has its own
>>> special pa
On 12/9/20 6:16 AM, John Hubbard wrote:
> On 12/8/20 9:28 AM, Joao Martins wrote:
>> Replace vmem_altmap with an vmem_context argument. That let us
>> express how the vmemmap is gonna be initialized e.g. passing
>> flags and a page size for reusing pages upon initia
On 12/9/20 4:40 AM, John Hubbard wrote:
> On 12/8/20 9:28 AM, Joao Martins wrote:
>> Much like hugetlbfs or THPs, we treat device pagemaps with
>> compound pages like the rest of GUP handling of compound pages.
>>
>> Rather than incrementing the refcount every 4K,
On 12/9/20 6:33 AM, Matthew Wilcox wrote:
> On Tue, Dec 08, 2020 at 09:59:19PM -0800, John Hubbard wrote:
>> On 12/8/20 9:28 AM, Joao Martins wrote:
>>> Add a new flag for struct dev_pagemap which designates that a a pagemap
>>
>> a a
>>
Ugh. Yeah will fix.
&
On 12/8/20 7:34 PM, Jason Gunthorpe wrote:
> On Tue, Dec 08, 2020 at 05:28:59PM +0000, Joao Martins wrote:
>> Rather than decrementing the ref count one by one, we
>> walk the page array and checking which belong to the same
>> compound_head. Later on we decrement
On 12/8/20 7:57 PM, Jason Gunthorpe wrote:
> On Tue, Dec 08, 2020 at 05:29:01PM +0000, Joao Martins wrote:
>> Similar to follow_hugetlb_page() add a follow_devmap_page which rather
>> than calling follow_page() per 4K page in a PMD/PUD it does so for the
>> entire PMD, wher
On 12/8/20 7:49 PM, Jason Gunthorpe wrote:
> On Tue, Dec 08, 2020 at 05:28:58PM +0000, Joao Martins wrote:
>> Much like hugetlbfs or THPs, we treat device pagemaps with
>> compound pages like the rest of GUP handling of compound pages.
>>
>> Rather than incrementin
On 12/8/20 7:29 PM, Jason Gunthorpe wrote:
> On Tue, Dec 08, 2020 at 05:29:00PM +0000, Joao Martins wrote:
>
>> static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem,
>> int dirty)
>> {
>> +bool make_dirty = umem->writable &&am
On 12/8/20 5:28 PM, Joao Martins wrote:
> Introduce a new flag, MEMHP_REUSE_VMEMMAP, which signals that that
> struct pages are onlined with a given alignment, and should reuse the
> tail pages vmemmap areas. On that circunstamce we reuse the PFN backing
> only the tail pages subsec
.
Signed-off-by: Joao Martins
---
I wonder, rather than separating vmem_context and mhp_params, that
one would just pick the latter. Albeit semantically the ctx aren't
necessarily paramters, context passed from multiple sections onlining
(i.e. multiple calls to populate_section_memmap). Also provided
1208 (commit a9e26cb5f261).
Comments and suggestions very much appreciated!
Thanks,
Joao
Joao Martins (9):
memremap: add ZONE_DEVICE support for compound pages
sparse-vmemmap: Consolidate arguments in vmemmap section populate
sparse-vmemmap: Reuse vmemmap areas for a given page size
-by: Joao Martins
---
include/linux/memremap.h | 2 ++
mm/memremap.c| 8 ++--
mm/page_alloc.c | 7 +++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 79c49e7f5c30..f8f26b2cc3da 100644
--- a/include
s -> ~19k us
Signed-off-by: Joao Martins
---
I've special-cased this to device-dax vmas given its similar page size
guarantees as hugetlbfs, but I feel this is a bit wrong. I am
replicating follow_hugetlb_page() as RFC ought to seek feedback whether
this should be generalized if no fundamental
sec: 10748.456 usec / round (hugetlbfs)
After:
305 rounds in 5.010 sec: 16426.047 usec / round (device-dax)
1073 rounds in 5.004 sec: 4663.622 usec / round (hugetlbfs)
We also see similar improvements on a setup with pmem and RDMA hardware.
Signed-off-by: Joao Martins
---
drivers/infiniband
Rather than decrementing the ref count one by one, we
walk the page array and checking which belong to the same
compound_head. Later on we decrement the calculated amount
of references in a single write to the head page.
Signed-off-by: Joao Martins
---
mm/gup.c | 41
get_user_pages_fast() and pin_user_pages_fast():
$ gup_benchmark -f /dev/dax0.2 -m 16384 -r 10 -S [-u,-a] -n 512 -w
(get_user_pages_fast 2M pages) ~75k us -> ~3.6k us
(pin_user_pages_fast 2M pages) ~125k us -> ~3.8k us
Signed-off-by: Joao Martins
---
mm/gup.
less pages.
On emulated NVDIMM guests this can be easily seen, e.g. on a setup
with an emulated NVDIMM with 128G in size seeing improvements from ~750ms
to ~190ms with 2M pages, and to less than a 1msec with 1G pages.
Signed-off-by: Joao Martins
---
Probably deserves its own sysfs attribute
or 262144 for a 1G @align.
Signed-off-by: Joao Martins
---
mm/memremap.c | 4 +++-
mm/page_alloc.c | 23 ---
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index ecfa74848ac6..3eca07916b9d 100644
--- a/mm/memremap.c
+++ b/mm
Replace vmem_altmap with an vmem_context argument. That let us
express how the vmemmap is gonna be initialized e.g. passing
flags and a page size for reusing pages upon initializing the
vmemmap.
Signed-off-by: Joao Martins
---
include/linux/memory_hotplug.h | 6 +-
include/linux/mm.h
.
Signed-off-by: Joao Martins
---
I wonder, rather than separating vmem_context and mhp_params, that
one would just pick the latter. Albeit semantically the ctx aren't
necessarily paramters, context passed from multiple sections onlining
(i.e. multiple calls to populate_section_memmap). Also
gned-off-by: Zhang Qilong
Reviewed-by: Joao Martins
> ---
> drivers/dax/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 27513d311242..e15a1a7c2853 100644
> --- a/drivers/dax/bus.c
> ++
On 9/25/20 10:01 PM, Dan Williams wrote:
> On Fri, Sep 25, 2020 at 1:52 PM Joao Martins
> wrote:
>>
>> Hey Dan,
>>
>> On 9/25/20 8:11 PM, Dan Williams wrote:
>>> Changes since v4 [1]:
>>> - Rebased on
>>> device-dax-move-instance-creatio
Hey Dan,
On 9/25/20 8:11 PM, Dan Williams wrote:
> Changes since v4 [1]:
> - Rebased on
> device-dax-move-instance-creation-parameters-to-struct-dev_dax_data.patch
> in -mm [2]. I.e. patches that did not need fixups from v4 are not
> included.
>
> - Folded all fixes
>
Hmm, perhaps you
[Sorry for the late response]
On 8/21/20 11:06 AM, David Hildenbrand wrote:
> On 03.08.20 07:03, Dan Williams wrote:
>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>> * could be mixed in a node with faster memory, causing
>> * unavoidable performance issues.
>>
On 8/31/20 12:32 PM, Dan Carpenter wrote:
> Hello Dan Williams,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 454c727769f5: "device-dax: add dis-contiguous resource
> support" from Aug 26, 2020, leads to the following Smatch complaint:
>
>
On 7/13/20 5:08 PM, Joao Martins wrote:
> Add a couple tests which exercise the new sysfs based
> interface for Soft-Reserved regions (by EFI/HMAT, or
> efi_fake_mem).
>
> The tests exercise the daxctl orchestration surrounding
> for creating/disabling/destroying/rec
On 7/16/20 5:00 PM, Dan Williams wrote:
> On Thu, Jul 16, 2020 at 6:19 AM Joao Martins
> wrote:
>> On 7/12/20 5:28 PM, Dan Williams wrote:
>>> In support of interrogating the physical address layout of a device with
>>> dis-contiguous ranges, introduce a sysf
Add the following APIs to be able to iterate over a
dynamic device-dax mapping list, as well as fetching
each of the mapping attributes.
Signed-off-by: Joao Martins
---
daxctl/lib/libdaxctl-private.h | 8
daxctl/lib/libdaxctl.c | 91
. It also allows an userspace application to pick
it's own ranges, should it want to avoid relying on kernel's policy.
Signed-off-by: Joao Martins
---
daxctl/lib/libdaxctl.c | 27 +++
daxctl/lib/libdaxctl.sym | 1 +
daxctl/libdaxctl.h | 2 ++
3 files changed, 30
1 - 100 of 160 matches
Mail list logo
