On 10/31/2017 11:40 AM, Marc-André Lureau wrote:
> The functions are called through shmem_fcntl() only.
And no danger in removing the EXPORTs as the routines only work
with shmem file structs.
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> --
TLBFS defined without CONFIG_TMPFS
is unlikely, but I think possible. Based on the above #ifdef/#else, I
think hugetlbfs seals will not work if CONFIG_TMPFS is not defined.
--
Mike Kravetz
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 37260c5e12fa..b7811979611f 100644
> --- a/m
l need to be accessed by code in mm/shmem.c
for file sealing operations. Move inode information definition from .c
file to header for needed access.
--
Mike Kravetz
>
> Signed-off-by: Marc-André Lureau
> ---
> fs/hugetlbfs/inode.c| 10 --
> include/linux/hugetlb.h | 10
: added similar check as shmem_setattr() & shmem_fallocate()
>
> Except write() operation that doesn't exist with hugetlbfs, that
> should make sealing as close as it can be to shmem support.
>
> Signed-off-by: Marc-André Lureau
Looks fine to me,
Reviewed-by: Mike Kravetz
--
M
endif
> +
> + return NULL;
> +}
> +
As mentioned in patch 2, I think this code will need to be restructured
so that hugetlbfs file sealing will work even is CONFIG_TMPFS is not
defined. The above routine is behind #ifdef CONFIG_TMPFS.
In general the code looks
n addition,
even though applications shouldn't care where new mappings are placed it
would not surprise me that such a change will be noticeable to some.
--
Mike Kravetz
gt;> think hugetlbfs seals will not work if CONFIG_TMPFS is not defined.
>
> Good point, memfd_create() will not exists either.
>
> I think this is a separate concern, and preexisting from this patch series
> though.
Ah yes. I should have addressed this when adding hugetlb
header for needed access.
>
> Ok, Does the patch get your Reviewed-by tag with that change?
>
> thanks
>
Yes, you can add
Reviewed-by: Mike Kravetz
with an updated commit message.
--
Mike Kravetz
we do not really
need to worry about those special (a)io cases for hugetlbfs.
--
Mike Kravetz
> you need to make sure there are no page references
> left around. For instance, on shmem any process might trigger the
> kernel to GUP mapped shmem pages for asynchronous IO, then unm
On 11/03/2017 10:41 AM, David Herrmann wrote:
> Hi
>
> On Fri, Nov 3, 2017 at 6:12 PM, Mike Kravetz wrote:
>> On 11/03/2017 10:03 AM, David Herrmann wrote:
>>> Hi
>>>
>>> On Tue, Oct 31, 2017 at 7:40 PM, Marc-André Lureau
>>> wrote:
>>&g
hough.
>>
>> Ah yes. I should have addressed this when adding hugetlbfs memfd_create
>> support.
>>
>> Of course, one 'simple' way to address this would be to make CONFIG_HUGETLBFS
>> depend on CONFIG_TMPFS. Not sure what people think about this?
>>
>
On 11/03/2017 10:56 AM, Mike Kravetz wrote:
> On 11/03/2017 10:41 AM, David Herrmann wrote:
>> Hi
>>
>> On Fri, Nov 3, 2017 at 6:12 PM, Mike Kravetz wrote:
>>> On 11/03/2017 10:03 AM, David Herrmann wrote:
>>>> Hi
>>>>
>>>&
MFD_HUGE_STR;
else
memfd_str = MEMFD_STR;
then prepend output strings with memfd_str.
This is just a suggestion and optional.
--
Mike Kravetz
>
> Signed-off-by: Marc-André Lureau
> ---
> tools/testing/selftests/memfd/memfd_test.c | 150
> +++--
well. Although, in practice one does tend
to use a single huge pages size. If you change the default huge page
size, then those entries will be in /proc/meminfo.
--
Mike Kravetz
ach. The 'trick' is coming up with a name or
description that is not confusing. Unfortunately, we have to leave the
existing entries. So, this new entry will be greater than or equal to
HugePages_Total. :( I guess Hugetlb is as good of a name as any?
--
Mike Kravetz
On 09/18/2017 06:45 AM, Florian Weimer wrote:
> On 09/15/2017 11:53 PM, Mike Kravetz wrote:
>> +If the value of \fIold_size\fP is zero, and \fIold_address\fP refers to
>> +a private anonymous mapping, then
>> +.BR mremap ()
>> +will create a new mapping of the
On 09/17/2017 06:52 PM, Jann Horn wrote:
> On Fri, Sep 15, 2017 at 2:37 PM, Mike Kravetz wrote:
> [...]
>> A recent change was made to mremap so that an attempt to create a
>> duplicate a private mapping will fail.
>>
>> commit dba58d3b8c5045ad89c1c95d33d01451e3
. This was used to create a 'duplicate mapping'.
A recent change was made to mremap so that an attempt to create a
duplicate a private mapping will fail.
Document the 'old_size == 0' behavior and new return code from
below commit.
commit dba58d3b8c5045ad89c1c95d33d01451e3964db7
Author: Mike Kravetz
Date
to work (ever?) in
such situations. If so, should we perhaps add a IS_DAX like check and
return something like EINVAL? Or, at least document expected behavior?
If madvise(MADV_HWPOISON) will not work, how can one inject errors to
test error handling code?
--
Mike Kravetz
rnel.org/r/20171107122800.25517-1-marcandre.lur...@redhat.com
Mike Kravetz (3):
mm: hugetlbfs: move HUGETLBFS_I outside #ifdef CONFIG_HUGETLBFS
mm: memfd: split out memfd for use by multiple filesystems
mm: memfd: remove memfd code from shmem files and use new memfd files
fs/Kconfig | 3 +
Remove memfd and file sealing routines from shmem.c and enable the
use of the new files (memfd.c and memfd.h). A new config option
MEMFD_CREATE is defined that is enabled if TMPFS -or- HUGETLBFS is
defined.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c
HUGETLBFS_I will be referenced but not used in code outside #ifdef
CONFIG_HUGETLBFS. Move the definition to prevent compiler errors.
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/include
When memfd_create support was originally written, it only provided
suport for tmpfs. Support has recently been added for hugetlbfs.
memfd originally depended on tmpfs. In an effort to make it depend
on tmpfs -or- hugetlbfs, split out the required code to separate
files.
Signed-off-by: Mike
d/or an mmapped file.
>
> It will work the way it is supposed to with anonymous MAP_PRIVATE
> memory, which is likely the only memory it will be used on, anyway.
>
Seems reasonable.
You should also add VM_HUGETLB to those returning -EINVAL. IIRC, a
VM_HUGETLB vma even without VM_SHARED expects vm_file != NULL.
--
Mike Kravetz
On 08/11/2017 09:59 AM, Rik van Riel wrote:
> On Fri, 2017-08-11 at 09:36 -0700, Mike Kravetz wrote:
>> On 08/11/2017 08:23 AM, Rik van Riel wrote:
>>> On Thu, 2017-08-10 at 17:23 +0200, Michal Hocko wrote:
>>>> On Sun 06-08-17 10:04:25, Rik van Riel wrote:
>&g
, therefore specifying
MFD_ALLOW_SEALING with MFD_HUGETLB will result in EINVAL.
Signed-off-by: Mike Kravetz
Acked-by: Michal Hocko
---
include/uapi/linux/memfd.h | 24
mm/shmem.c | 37 +++--
2 files changed, 55 insertions(+), 6
, a new patch is included to modify the memfd selftest. The
modifications allow basic functionality testing of memfd_create with
hugetlbfs.
Mike Kravetz (2):
mm/shmem: add hugetlbfs support to memfd_create()
selftests/memfd: Add memfd_create hugetlbfs selftest
include/uapi/linux/memfd.h
. At
the end of testing, it will release any huge pages allocated for testing
purposes.
Signed-off-by: Mike Kravetz
---
tools/testing/selftests/memfd/Makefile | 2 +-
tools/testing/selftests/memfd/memfd_test.c | 372 ++---
tools/testing/selftests/memfd/run_tests.sh | 69
.
Mike Kravetz (1):
mm/cma: fix alloc_contig_range ret code/potential leak
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.13.6
().
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation
failure")
Cc:
Signed-off-by: Mike Kravetz
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 77e4d3c5c57b..3605ca82fd29 10064
On 11/20/2017 02:28 AM, Marc-André Lureau wrote:
> Hi
>
> On Thu, Nov 9, 2017 at 2:41 AM, Mike Kravetz wrote:
>> With the addition of memfd hugetlbfs support, we now have the situation
>> where memfd depends on TMPFS -or- HUGETLBFS. Previously, memfd was only
>> sup
t; I'm not understanding this test. Are we assuming that default_hstate
> always refers to the highest-index hstate? If so why, and is that
> valid?
Actually default_hstate is defined as:
#define default_hstate (hstates[default_hstate_idx])
default_hstate_idx is set during hugetlb_init based
-Wmaybe-uninitialized]
You have added a way of getting out of that big if/else if statement without
setting mhp. mhp will be examined later in the code, so this is indeed a bug.
Like Aneesh, I am not sure if there is great benefit in this patch.
You added this change in functionality only for powerpc. IMO, it would be
best if behavior was consistent in all architectures. So, if we change it
for powerpc we may want to change everywhere.
--
Mike Kravetz
c
89 e7 e8 1d 7e 03 00 0f 0b 48 c7 c6 00 f4 c5 81 4c 89 e7 e8 0c 7e 03 00 <0f> 0b
48 c7 c6 38 f3 c5 81 4c 89 e7 e8 fb 7d 03 00 0f 0b 48 c7
[ 694.606500] RIP: __delete_from_page_cache+0x344/0x410 RSP: c900019d7a88
[ 694.607426] ---[ end trace 55e6b04ae95d8ce3 ]---
BTW, this was on 4.13.0
On 08/21/2017 11:07 AM, Catalin Marinas wrote:
> On Fri, Aug 18, 2017 at 02:29:18PM -0700, Mike Kravetz wrote:
>> On 08/18/2017 07:54 AM, Punit Agrawal wrote:
>>> When walking the page tables to resolve an address that points to
>>> !p*d_present() entry, huge_pte_of
on-zero as we have
successfully added it to the page cache. So, we are not freeing the
page here, just dropping the reference count.
This should not cause a problem like that seen in madvise.
--
Mike Kravetz
On 08/25/2017 03:51 PM, Nadav Amit wrote:
> Mike Kravetz wrote:
>
>> On 08/25/2017 03:02 PM, Nadav Amit wrote:
>>> Michal Hocko wrote:
>>>
>>>> Hmm, I do not see this neither in linux-mm nor LKML. Strange
>>>>
>>>> On We
ugetlbfs_fallocate()")
>
> cc: Eric Biggers
> cc: Mike Kravetz
>
> Signed-off-by: Nadav Amit
Thank you Nadav.
Reviewed-by: Mike Kravetz
Since hugetlbfs is an in memory filesystem, the only way one 'should' be
able to remove a page (file content) is through an inode operati
Adding Andrew, Michal on CC
On 08/27/2017 01:08 PM, Nadav Amit wrote:
> Mike Kravetz wrote:
>
>> On 08/26/2017 12:11 PM, Nadav Amit wrote:
>>> hugetlfs_fallocate() currently performs put_page() before unlock_page().
>>> This scenario opens a small time window, f
On 08/28/2017 11:09 AM, Michal Hocko wrote:
> On Mon 28-08-17 10:45:58, Mike Kravetz wrote:
>> Adding Andrew, Michal on CC
>>
>> On 08/27/2017 01:08 PM, Nadav Amit wrote:
>>> Mike Kravetz wrote:
>>>
>>>> On 08/26/2017 12:11 PM, Nadav Amit w
into anonymous mappings? What happens to file references?
What about the really ugly case of hugetlb mappings? Do they get
'transformed' to non-hugetlb mappings? Or, do you create a separate
hugetlb mapping for the child?
--
Mike Kravetz
to encode huge page size in the
flag arguments.
hugetlbfs does not support sealing operations, therefore specifying
MFD_ALLOW_SEALING with MFD_HUGETLB will result in EINVAL.
Signed-off-by: Mike Kravetz
---
include/uapi/linux/memfd.h | 24
mm/shmem.c | 37
/564
Mike Kravetz (1):
mm/shmem: add hugetlbfs support to memfd_create()
include/uapi/linux/memfd.h | 24
mm/shmem.c | 37 +++--
2 files changed, 55 insertions(+), 6 deletions(-)
--
2.7.5
tlb_fault is the
only caller of hugetlb_no_page, so this should be pretty straight forward.
Were you thinking of additional improvements?
--
Mike Kravetz
On 08/08/2017 06:15 AM, Rik van Riel wrote:
> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote:
>> On 08/07/2017 08:23 PM, Mike Kravetz wrote:
>>> If my thoughts above are correct, what about returning EINVAL if
>>> one
>>> attempts to set MADV_DON
and discourage its use.
A recent change was made to mremap so that an attempt to create a
duplicate a private mapping will fail.
commit dba58d3b8c5045ad89c1c95d33d01451e3964db7
Author: Mike Kravetz
Date: Wed Sep 6 16:20:55 2017 -0700
mm/mremap: fail map duplication attempts for private
hugetlbfs support for memfd_create was recently merged by Linus and
should be in the Linux 4.14 release. To request hugetlbfs support
a new memfd_create flag (MFD_HUGETLB) was added.
This patch documents the following commit:
commit 749df87bd7bee5a79cef073f5d032ddb2b211de8
Author: Mike Kravetz
CC: linux-mm
On 09/15/2017 02:37 PM, Mike Kravetz wrote:
> Since at least the 2.6 time frame, mremap would create a new mapping
> of the same pages if 'old_size == 0'. It would also leave the original
> mapping. This was used to create a 'duplicate mapping'.
>
> Docume
CC: linux-mm
On 09/15/2017 02:43 PM, Mike Kravetz wrote:
> hugetlbfs support for memfd_create was recently merged by Linus and
> should be in the Linux 4.14 release. To request hugetlbfs support
> a new memfd_create flag (MFD_HUGETLB) was added.
>
> This patch documents the f
On 07/26/2017 03:07 AM, Michal Hocko wrote:
> On Wed 26-07-17 11:53:38, Michal Hocko wrote:
>> On Mon 17-07-17 15:28:01, Mike Kravetz wrote:
>>> Use the common definitions from hugetlb_encode.h header file for
>>> encoding hugetlb size definitions in shmget system c
offset might have
different semantics. I have not reviewed all the arch specific instances
of the routine to know if this is even possible. Just curious if you
examined these, or perhaps you think this is not an issue?
--
Mike Kravetz
On 07/27/2017 12:50 AM, Michal Hocko wrote:
> On Wed 26-07-17 10:39:30, Mike Kravetz wrote:
>> On 07/26/2017 03:07 AM, Michal Hocko wrote:
>>> On Wed 26-07-17 11:53:38, Michal Hocko wrote:
>>>> On Mon 17-07-17 15:28:01, Mike Kravetz wrote:
>>>>> Use
this assume that there is
a pre-allocated gigantic page sitting unused that will be the target
of the migration? alloc_huge_page_node will not allocate a gigantic
page. Or, am I missing something?
--
Mike Kravetz
>
> While allocating the new gigantic HugeTLB page, it should not matter
> whethe
d7a ("hugetlb: add support for gigantic page allocation at
> runtime")
> Signed-off-by: Michal Hocko
This seems reasonable to me, and I like the fact that the code is more
like the default huge page case. I don't see any issues with the code.
I did some simple smoke testing of allo
On 04/04/2018 04:36 AM, Anders Roxell wrote:
> On 14 March 2018 at 02:09, Mike Kravetz wrote:
>> On 03/13/2018 04:42 AM, Anders Roxell wrote:
>>> gcc warns about implicit declaration.
>>>
>>> gcc -D_FILE_OFFSET_BITS=64 -I../../../../include/uapi/
>>>
On 04/12/2018 01:40 PM, Reinette Chatre wrote:
> Hi Mike,
>
> On 2/15/2018 12:22 PM, Reinette Chatre wrote:
>> On 2/12/2018 2:20 PM, Mike Kravetz wrote:
>>> These patches came out of the "[RFC] mmap(MAP_CONTIG)" discussions at:
>>> http://lkml.ker
On 04/22/2018 05:09 PM, Michal Hocko wrote:
> On Mon 16-04-18 19:09:14, Mike Kravetz wrote:
> [...]
>> @@ -2010,9 +2011,13 @@ static __always_inline struct page
>> *__rmqueue_cma_fallback(struct zone *zone,
>> {
>> return __rmqueue_smallest(zone, order, M
mm/shmem.c are fixed
in patch 1. Patch 2 updates comments and file checking such that patch
3 is only code movement.
Mike Kravetz (3):
mm/shmem: add __rcu annotations and properly deref radix entry
mm/shmem: update file sealing comments and file checking
mm: restructure memfd code
-off-by: Mike Kravetz
---
mm/shmem.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index c7bad16fe884..be20fc388dcb 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2734,11 +2734,11 @@ static int shmem_wait_for_pins(struct
changes are made to the code: restructuring only.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c | 2 +-
include/linux/memfd.h| 16 +++
include/linux/shmem_fs.h | 13 --
mm/Makefile | 1 +
mm/memfd.c | 344
In preparation for memfd code restucture, clean up sparse warnings.
Most changes required adding __rcu annotations. The routine
find_swap_entry was modified to properly deference radix tree
entries.
Signed-off-by: Mike Kravetz
Signed-off-by: Matthew Wilcox
---
mm/shmem.c | 20
On 04/09/2018 06:41 PM, Matthew Wilcox wrote:
> On Mon, Apr 09, 2018 at 04:05:05PM -0700, Mike Kravetz wrote:
>> +/*
>> + * We need a tag: a new tag would expand every radix_tree_node by 8 bytes,
>> + * so reuse a tag which we firmly believe is never set or cleared on shmem
rom f9f98e0d6fd87af4b48befbad757467f834a868c Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Mon, 9 Apr 2018 13:04:38 -0700
Subject: [PATCH 2/3] mm/shmem: update file sealing comments and file checking
In preparation for memfd code restructure, update comments,
definitions and function names dealing with file sealing to
indic
On 04/09/2018 08:03 PM, Mike Kravetz wrote:
> On 04/09/2018 06:41 PM, Matthew Wilcox wrote:
>> On Mon, Apr 09, 2018 at 04:05:05PM -0700, Mike Kravetz wrote:
>>> +/*
>>> + * We need a tag: a new tag would expand every radix_tree_node by 8 bytes,
>>> + * so
In preparation for memfd code restucture, clean up sparse warnings.
Most changes required adding __rcu annotations. The routine
find_swap_entry was modified to properly deference radix tree
entries.
Signed-off-by: Mike Kravetz
Signed-off-by: Matthew Wilcox
---
mm/shmem.c | 20
referencing
file_operation structs.
Signed-off-by: Mike Kravetz
---
mm/shmem.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index c7bad16fe884..a8bff40a10cd 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
his
series. Specifically, the last patch.
While redoing the series, all sparse warnings in mm/shmem.c are fixed
in patch 1. Patch 2 updates comments, definitions, function names and
file checking such that patch 3 is code movement only.
v4 adds more cleanups in patch 2 before code movement.
Mike Kravetz
changes are made to the code: restructuring only.
Signed-off-by: Mike Kravetz
---
fs/Kconfig | 3 +
fs/fcntl.c | 2 +-
include/linux/memfd.h| 16 +++
include/linux/shmem_fs.h | 13 --
mm/Makefile | 1 +
mm/memfd.c | 345
an unsigned int.
However, this should be changed to an unsigned long to be consistent
with other page counts.
Signed-off-by: Mike Kravetz
---
include/linux/gfp.h | 2 +-
mm/cma.c| 2 +-
mm/hugetlb.c| 2 +-
mm/page_alloc.c | 6 +++---
4 files changed, 6 insertions(+), 6
delete all the supporting code in hugetlb.c.
A new use case for allocating contiguous memory has been identified in
Intel(R) Resource Director Technology Cache Pseudo-Locking.
Mike Kravetz (3):
mm: change type of free_contig_range(nr_pages) to unsigned long
mm: add find_alloc_contig_pages() inte
Use the new find_alloc_contig_pages() interface for the allocation of
gigantic pages and remove associated code in hugetlb.c.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 87 +---
1 file changed, 6 insertions(+), 81 deletions(-)
diff
is employed
if possible. There is no guarantee that the routine will succeed.
So, the user must be prepared for failure and have a fall back plan.
Signed-off-by: Mike Kravetz
---
include/linux/gfp.h | 12
mm/page_alloc.c | 89 +++--
2
bit kernels.
On 32 bit kernels conversion from a page based unsigned long can
not overflow a loff_t byte offset. Therefore, skip this check
if sizeof(unsigned long) != sizeof(loff_t).
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Cc:
Reported-by: Dan Rue
Signed-of
atic void free_contig_pages(struct page *page, unsigned long nr_pages)
> ^
Build issues fixed in updated patch below,
>From 28efabb5625c079573a821c8c5cfc19cc73a86bd Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Mon, 16 Apr 2018 18:41:36 -0700
Subject: [PAT
d address.
IIRC, there is code to 'suitably align' DAX mappings to appropriate huge page
boundaries. Perhaps, something like this could be added for tmpfs mounted
with huge=? Of course, this would not take into account 'length' but may
help some.
--
Mike Kravetz
On 03/02/2018 05:39 PM, Mike Kravetz wrote:
> On 03/02/2018 04:56 PM, Andrew Morton wrote:
>> On Fri, 2 Mar 2018 16:38:33 -0800 Mike Kravetz
>> wrote:
>>
>>> On 03/02/2018 04:06 PM, Andrew Morton wrote:
>>>> On Mon, 26 Feb 201
off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0aa2896..cb288dec5564 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -127,12 +127,13 @@ static
On 03/07/2018 05:35 PM, Yisheng Xie wrote:
> Hi Mike,
>
> On 2018/3/8 7:59, Mike Kravetz wrote:
>> A vma with vm_pgoff large enough to overflow a loff_t type when
>> converted to a byte offset can be passed via the remap_file_pages
>> system call. The hugetlbfs mmap r
> +./userfaultfd hugetlb $hugetlb_size 32 $mnt/ufd_test_file
> if [ $? -ne 0 ]; then
> echo "[FAIL]"
> exitcode=1
The above changes are functionally OK. But, I think something like the
following may be easier to read/understand. Feel free to use as much or
littl
On 03/02/2018 04:06 PM, Andrew Morton wrote:
> On Mon, 26 Feb 2018 11:10:54 -0800 Mike Kravetz
> wrote:
>
>> start_isolate_page_range() is used to set the migrate type of a
>> set of page blocks to MIGRATE_ISOLATE while attempting to start
>> a migration operation
On 03/02/2018 04:56 PM, Andrew Morton wrote:
> On Fri, 2 Mar 2018 16:38:33 -0800 Mike Kravetz
> wrote:
>
>> On 03/02/2018 04:06 PM, Andrew Morton wrote:
>>> On Mon, 26 Feb 2018 11:10:54 -0800 Mike Kravetz
>>> wrote:
>>>
>>>> star
to reflect this new functionality.
Signed-off-by: Mike Kravetz
---
mm/page_alloc.c | 8
mm/page_isolation.c | 10 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cb416723538f..02a17efac233 100644
--- a/mm/page_alloc.c
+++ b
s probably a
good idea to fix this issue. Because this is so unlikely, I am not
sure if this should got to stable releases as well.
Mike Kravetz (1):
mm: make start_isolate_page_range() fail if already isolated
mm/page_alloc.c | 8
mm/page_isolation.c | 10 +-
2 files c
s from breaking up":
http://lkml.kernel.org/r/alpine.DEB.2.20.1802091311090.3059@nuc-kabylake
find_alloc_contig_pages() uses the same logic that exists today for scanning
zones to look for contiguous ranges suitable for gigantic pages. The last
patch in the series changes gigantic page allocation t
mechanism and will allow for more general use
of callers making use of these interfaces.
Signed-off-by: Mike Kravetz
---
mm/page_alloc.c | 8
mm/page_isolation.c | 10 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index
a range of pages, migration is employed
if possible. There is no guarantee that the routine will succeed.
So, the user must be prepared for failure and have a fall back plan.
Signed-off-by: Mike Kravetz
---
include/linux/gfp.h | 12
mm/page_alloc.c | 89
Use the new find_alloc_contig_pages() interface for the allocation of
gigantic pages.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 88 +---
1 file changed, 6 insertions(+), 82 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
So, at a minimum this is a
'heads up'. If there are actual use cases that depend on this, then more
work/discussions will need to happen. From the e-mail thread on PGD_SIZE
support, I can not tell if there is a real use case or this is just a
'nice to have'.
--
Mike Kravetz
>> Folks, this pa
exclusive,
> - so you can NOT specify nn[KMGTPE] and "mirror" at the
> same
> - time.
> + for Movable pages. "nn[KMGTPE]", "nn%", and "mirror"
> + are exclusive, so you cannot specify multiple forms.
>
> kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port.
> Format: [,poll interval]
Don't you need to make the same type percentage changes for 'movablecore='?
--
Mike Kravetz
On 02/13/2018 05:00 PM, David Rientjes wrote:
> Specify that movablecore= can use a percent value.
>
> Remove comment about hugetlb pages not being movable per Mike.
>
> Cc: Mike Kravetz
> Signed-off-by: David Rientjes
Thanks! FWIW,
Reviewed-by: Mike Kravetz
And, that is
> Not only this removes quite some code it also should make those layers
> easier to follow and clear wrt responsibilities.
>
> Changes since v1
> - pulled gfp mask out of __hugetlb_alloc_buddy_huge_page and make it an
> explicit argument to allow __GFP_THISNODE in a
implify dequeue_huge_page_nodemask and alloc_huge_page_nodemask a bit
> as per Vlastimil
Reviewed-by: Mike Kravetz
Tested-by: Mike Kravetz
--
Mike Kravetz
>
> Acked-by: Vlastimil Babka
> Signed-off-by: Michal Hocko
> ---
> include/linu
c_huge_page_node(nid) would check on this
> specific node.
Reviewed-by: Mike Kravetz
Tested-by: Mike Kravetz
--
Mike Kravetz
>
> Noticed-by: Vlastimil Babka
> Acked-by: Vlastimil Babka
> Signed-off-by: Michal Hocko
> ---
> mm/memory-failure.c | 10 +-
> 1 file cha
On 07/12/2017 04:46 AM, Michal Hocko wrote:
> On Tue 11-07-17 11:23:19, Mike Kravetz wrote:
>> On 07/11/2017 05:36 AM, Michal Hocko wrote:
> [...]
>>> Anyway the patch should fail with -EINVAL on private mappings as Kirill
>>> already pointed out
>>
>> Yes
to the original.
This is contrary to the purpose of mremap which should return
a mapping which is in some way related to the original.
Therefore, return EINVAL in the case where if an attempt is
made to duplicate a private mapping.
Signed-off-by: Mike Kravetz
---
mm/mremap.c | 7 +++
1 file changed, 7
On 07/12/2017 11:16 PM, Michal Hocko wrote:
> On Wed 12-07-17 09:55:48, Mike Kravetz wrote:
>> On 07/12/2017 04:46 AM, Michal Hocko wrote:
>>> On Tue 11-07-17 11:23:19, Mike Kravetz wrote:
>>>> On 07/11/2017 05:36 AM, Michal Hocko wrote:
>>> [...]
>>
On 07/13/2017 09:30 AM, Andrea Arcangeli wrote:
> On Thu, Jul 13, 2017 at 09:01:54AM -0700, Mike Kravetz wrote:
>> Sent a patch (in separate e-mail thread) to return EINVAL for private
>> mappings.
>
> The way old_len == 0 behaves for MAP_PRIVATE seems more sane to me
&
On 07/13/2017 12:11 PM, Vlastimil Babka wrote:
> [+CC linux-api]
>
> On 07/13/2017 05:58 PM, Mike Kravetz wrote:
>> mremap will create a 'duplicate' mapping if old_size == 0 is
>> specified. Such duplicate mappings make no sense for private
>> mappings. If duplication
On 07/14/2017 01:26 AM, Michal Hocko wrote:
> On Thu 13-07-17 15:33:47, Mike Kravetz wrote:
>> On 07/13/2017 12:11 PM, Vlastimil Babka wrote:
>>> [+CC linux-api]
>>>
>>> On 07/13/2017 05:58 PM, Mike Kravetz wrote:
>>>> mremap will create a 'dupli
On 07/07/2017 04:03 AM, Anshuman Khandual wrote:
> On 07/06/2017 09:47 PM, Mike Kravetz wrote:
>> The mremap system call has the ability to 'mirror' parts of an existing
>> mapping. To do so, it creates a new mapping that maps the same pages as
>> the original mapping, just a
801 - 900 of 2070 matches
Mail list logo
