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
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 <marcandre.lur...@redhat.com>
> ---
> tools/testing/selftests/memfd/memfd_test.c | 150
> +++--
On 11/06/2017 06:39 AM, Marc-André Lureau wrote:
> Remove most of the special-casing of hugetlbfs now that sealing
> is supported.
>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
On 11/06/2017 06:39 AM, Marc-André Lureau wrote:
> Suggested-by: Mike Kravetz <mike.krav...@oracle.com>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
> ---
> tools/testing/sel
On 11/06/2017 06:39 AM, Marc-André Lureau wrote:
> The memfd & fuse tests will share more common code in the following
> commits to test hugetlb support.
>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Mike Kravetz <mike.krav...@orac
On 11/06/2017 06:39 AM, Marc-André Lureau wrote:
> Suggested-by: Mike Kravetz <mike.krav...@oracle.com>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> ---
> tools/testing/selftests/memfd/fuse_test.c | 30
> ++
>
On 11/06/2017 06:39 AM, Marc-André Lureau wrote:
> Hi,
>
> Recently, Mike Kravetz added hugetlbfs support to memfd. However, he
> didn't add sealing support. One of the reasons to use memfd is to have
> shared memory sealing when doing IPC or sharing memory with another
> proce
On 10/23/2017 03:10 PM, Dave Hansen wrote:
> On 10/03/2017 04:56 PM, Mike Kravetz wrote:
>> mmap(MAP_CONTIG) would have the following semantics:
>> - The entire mapping (length size) would be backed by physically contiguous
>> pages.
>> - If 'length' phys
> sorry for the inconvenience.
>
> On 2017-10-08 18:47 Mike Kravetz wrote:
>> You are correct. That check in function vma_to_resize() will prevent
>> mremap from growing or relocating hugetlb backed mappings. This check
>> existed in the 2.6.0 linux kernel, so this restriction
exit 1
> + exit $ksft_skip
We now KNOW that we are running as root because of the check above. We
can delete this test, and rely on the later check to determine if the
number of huge pages was actually increased.
How about this instead (untested)?
Signed-off-by: Mike Kravetz <mike
changes look fine to me.
> Signed-off-by: "Huang, Ying" <ying.hu...@intel.com>
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
> Cc: Andrea Arcangeli <aarca...@redhat.com>
> Cc: "Kirill A. Shutemov" <kirill.shute...@linux.intel.com
OSG) <sh...@kernel.org>
Thanks for making the changes!
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
> ---
>
> Changes since v1:
> -- addressed review comments on v1
> -- Fixed a regression in v1 that changed the behavior to require root
>for all
DONE
> ok 1..2 selftests: memfd: run_fuse_test.sh [PASS]
> selftests: memfd: run_hugetlbfs_test.sh
>
> Please run memfd with hugetlbfs test as root
> not ok 1..3 selftests: memfd: run_hugetlbfs_test.sh [SKIP]
>
> Signed-off-by: Shuah Khan (Samsung OSG) <sh...@kernel
s could be seen as other workload which generates heavy cache
> pressure. At the same time, the cache miss rate reduced from ~36.3%
> to ~25.6%, the IPC (instruction per cycle) increased from 0.3 to 0.37,
> and the time spent in user space is reduced ~19.3%.
>
Agree with Michal that com
On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote:
> Thanks to Mike Kravetz for comment on the previous version patch.
>
> The purpose of this patch-set is to make it possible to control whether or
> not to charge surplus hugetlb pages obtained by overcommitting to memory
> cgroup. I
On 05/21/2018 05:00 AM, Vlastimil Babka wrote:
> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>> Vlastimil and Michal brought up the issue of allocation alignment. The
>> routine will currently align to 'nr_pages' (which is the requested size
>> argument). It does this by
On 05/18/2018 03:32 AM, Vlastimil Babka wrote:
> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>> The routine start_isolate_page_range and alloc_contig_range have
>> comments saying that migratetype must be either MIGRATE_MOVABLE or
>> MIGRATE_CMA. However, this is not en
On 05/21/2018 01:54 AM, Vlastimil Babka wrote:
> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>> find_alloc_contig_pages() is a new interface that attempts to locate
>> and allocate a contiguous range of pages. It is provided as a more
>
> How about dropping the 'find_' f
On 05/22/2018 09:41 AM, Reinette Chatre wrote:
> On 5/21/2018 4:48 PM, Mike Kravetz wrote:
>> On 05/21/2018 01:54 AM, Vlastimil Babka wrote:
>>> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>>>> +/**
>>>> + * find_alloc_contig_pages() --
they are allocated as 'reserves'. It is not until these reserves are actually
used that accounting limits are checked. This 'seems' to align with general
allocation of huge pages within the pool. No accounting is done until they
are actually allocated to a mapping/file.
--
Mike Kravetz
tor.
I really do not think hugetlbfs overcommit will provide any benefit over
THP for your use case. Also, new user space code is required to "fall back"
to normal pages in the case of hugetlbfs page allocation failure. This
is not needed in the THP case.
--
Mike Kravetz
n hugetlb_cow(), so
> the "address" is renamed to "haddr" in hugetlb_cow() in this patch.
> Next patch will use target subpage address in hugetlb_cow() too.
>
> The patch is just code cleanup without any functionality changes.
>
> Signed-off-by: "
t calls. But with the proper inline support of the compilers,
> the indirect call will be optimized to be the direct call. Our tests
> show no performance change with the patch.
>
> This patch is a code cleanup without functionality change.
>
> Signed-off-by: "Huang
rites to the anonymous memory area from the begin to the end, so
> cause copy on write. For each child process, other child processes
> could be seen as other workloads which generate heavy cache pressure.
> At the same time, the IPC (instruction per cycle) increased from 0.63
> to 0.78
etlbfs huge
> page after the page fault under heavy cache contention.
>
> Signed-off-by: "Huang, Ying" <ying.hu...@intel.com>
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
> Cc: Mike Kravetz <mike.krav...@oracle.com>
> Cc: Mi
sub-pages are to be copied. IIUC, you
added the same algorithm for sub-page ordering to copy_huge_page()
that was previously added to clear_huge_page(). Correct? If so,
then perhaps a common helper could be used by both the clear and copy
huge page routines. It would also make maintenance easier.
--
Mike Kravetz
ifically, for copies as a result of a COW.
Is that another area to consider?
That gets back to Michal's question of a specific use case or generic
optimization. Unless code is simple (as in this patch), seems like we should
hold off on considering additional optimizations unless there is a specific
use case.
I'm still OK with this change.
--
Mike Kravetz
On 05/18/2018 02:12 AM, Vlastimil Babka wrote:
> On 05/04/2018 01:29 AM, Mike Kravetz wrote:
>> free_contig_range() is currently defined as:
>> void free_contig_range(unsigned long pfn, unsigned nr_pages);
>> change to,
>> void free_contig_range(unsigned long
. hugetlb.c and hugetlb.h are
not 100% hugetlbfs, but a majority of their content is hugetlbfs
related.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
MAINTAINERS | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9051a9
ssh_to_dbg # sudo ./test_mmap 4
mapping 4 huge pages
address 7f62bba0 read (-)
address 7f62bbc0 read (-)
Connection to dbg closed by remote host.
Connection to dbf closed.
OOM did kick in (lots of console/log output) and killed the shell
as well.
--
Mike Kravetz
On 05/30/2018 01:02 AM, Michal Hocko wrote:
> On Tue 29-05-18 15:21:14, Mike Kravetz wrote:
>> Just a quick heads up. I noticed a change in libhugetlbfs testing starting
>> with v4.17-rc1.
>>
>> V4.16 libhugetlbfs test results
>> ** TEST SUM
age. However, this does not seem right.
--
Mike Kravetz
libhugetlbfs tests for an unrelated
issue/change and, will do some analysis to see exactly what is happening.
Also, will take it upon myself to run libhugetlbfs test suite on a
regular (at least weekly) basis.
--
Mike Kravetz
tion. Unlike the case in ad55eac74f20, the access
permissions on section 1 (RE) are different than section 2 (RW). If we
allowed the previous MAP_FIXED behavior, we would be changing part of a
read only section to read write. This is exactly what MAP_FIXED_NOREPLACE
was designed to prevent.
--
Mike Kravetz
tfd is/can be enabled for impacted architectures.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> fs/userfaultfd.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 123bf7d516fc..594d192b2331 1006
: Cannon Matthews
My only suggestion would be to remove the mention of 2M pages in the
commit message. Thanks for adding this.
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> ---
> mm/hugetlb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index
not charged to a memcg. memcg charges in other
code paths seem to happen at huge page allocation time.
--
Mike Kravetz
>
> The page charged to memcg will finally be uncharged at free_huge_page.
>
> Modification of memcontrol.c is for updating of statistical information
>
On 04/21/2018 09:16 AM, Vlastimil Babka wrote:
> On 04/17/2018 04:09 AM, Mike Kravetz wrote:
>> find_alloc_contig_pages() is a new interface that attempts to locate
>> and allocate a contiguous range of pages. It is provided as a more
>> convenient interface than alloc
On 05/01/2018 11:54 PM, TSUKADA Koutaro wrote:
> On 2018/05/02 13:41, Mike Kravetz wrote:
>> What is the reason for not charging pages at allocation/reserve time? I am
>> not an expert in memcg accounting, but I would think the pages should be
>> charged at allocation tim
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 <mike.krav...@oracle.com>
---
include/linux/gfp.h | 12 +
mm/page_alloc.c
an unsigned int.
However, this should be changed to an unsigned long to be consistent
with other page counts.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
include/linux/gfp.h | 2 +-
mm/cma.c| 2 +-
mm/hugetlb.c| 2 +-
mm/page_alloc.c | 6 +++---
4
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 <mike.krav...@oracle.com>
---
mm/hugetlb.c | 87 +---
1 file changed, 6 inse
urce Director Technology Cache Pseudo-Locking.
Mike Kravetz (4):
mm: change type of free_contig_range(nr_pages) to unsigned long
mm: check for proper migrate type during isolation
mm: add find_alloc_contig_pages() interface
mm/hugetlb: use find_alloc_contig_pages() to allocate gigantic pa
as there are two primary
users. Contiguous range allocation which wants to enforce migration
type checking. Memory offline (hotplug) which is not concerned about
type checking.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
include/linux/page-isolation.h | 8 +++---
On 05/03/2018 05:09 PM, TSUKADA Koutaro wrote:
> On 2018/05/03 11:33, Mike Kravetz wrote:
>> On 05/01/2018 11:54 PM, TSUKADA Koutaro wrote:
>>> On 2018/05/02 13:41, Mike Kravetz wrote:
>>>> What is the reason for not charging pages at allocation/reserve time? I
pages to zero, the poisoned page will be counted as 'surplus'.
I was thinking about keeping at least a bad page count (if not
a list) to avoid user confusion. It may be overkill as I have
not given too much thought to this issue. Anyone else have
thoughts here?
Mike Kravetz (1):
mm:hugetlbfs
Cc: <sta...@vger.kernel.org>
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
fs/hugetlbfs/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 59073e9f01a4..ed113ea17aff 100644
--- a/fs/hugetlbfs/
empt to mirror private anon mapping will fail.
>
> Suggested-by: Mike Kravetz <mike.krav...@oracle.com>
> Signed-off-by: Anshuman Khandual <khand...@linux.vnet.ibm.com>
The tests themselves look fine. However, they are pretty simple and
could very easily be combined into
On 10/19/2017 07:30 PM, Naoya Horiguchi wrote:
> On Thu, Oct 19, 2017 at 04:00:07PM -0700, Mike Kravetz wrote:
>
> Thank you for addressing this. The patch itself looks good to me, but
> the reported issue (negative reserve count) doesn't reproduce in my trial
> with v4.14-rc5, so
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
On 12/20/2017 11:28 PM, Michal Hocko wrote:
> On Wed 20-12-17 14:43:03, Mike Kravetz wrote:
>> On 12/20/2017 01:53 AM, Michal Hocko wrote:
>>> On Wed 20-12-17 05:33:36, Naoya Horiguchi wrote:
>>>> I have one comment on the code path from mbind(2).
>>>
_SIZE) {
> + action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
> +
> if (!hwpoison_user_mappings(p, pfn, trapno, flags, )) {
> action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED);
> res = -EBUSY;
>
Thanks, that does catch all those other huge page sizes.
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
It would really be helpful to get some comments from the powerpc folks
as this does seem to impact them most. Perhaps arm64 as well?
--
Mike Kravetz
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 enabled.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
fs/K
applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/restructure-memfd-code/20180131-023405
> base: git://git.cmpxchg.org/linux-mmotm.git master
> reproduce:
> # apt-
-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
include/linux/memfd.h | 16 +++
mm/memfd.c| 342 ++
2 files changed, 358 insertions(+)
create mode 100644 include/linux/memfd.h
create mode 100644 mm/memfd.c
diff --git a/i
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 <mike.krav...@oracle.com>
---
include/linux/hugetlb.h | 27 ---
1 file changed, 16 insertions(
han MAX_ORDER contiguous pages?".
Not sure that we should be adding to the current alloc_contig_range
interface until we decide it is something which will be useful long term.
--
Mike Kravetz
this was sent as a RFC, one comment suggested combining patches 2
and 3 so that we would not have 'new unused' files between patches. If
this is desired, I can make the change. For me, it is easier to read
as separate patches.
v2:
- Fixed sparse warnings inherited from existing code
Mike Kravetz (3
-or- hugetlbfs, split out the required
memfd code to separate files.
These files are not used until a subsequent patch which deletes
duplicate code in the orifinal files and enables their use.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
include/linux/memfd.h | 16 +++
mm/m
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 enabled.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
fs/K
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 <mike.krav...@oracle.com>
---
include/linux/hugetlb.h | 27 ---
1 file changed, 16 insertions(
this was sent as a RFC, one comment suggested combining patches 2
and 3 so that we would not have 'new unused' files between patches. If
this is desired, I can make the change. For me, it is easier to read
as separate patches.
Mike Kravetz (3):
mm: hugetlbfs: move HUGETLBFS_I outside #ifdef
he 1st madvise() event.
>
> Do pgd size pages work properly?
Adding Anshuman and Aneesh as they added pgd support for power. And,
this patch will disable that as well IIUC.
This patch makes sense for x86. My only concern/question is for other
archs which may have huge page sizes defi
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 <mike.krav...@oracle.com>
---
include/linux/gfp.h | 12
mm/page_alloc.c
Use the new find_alloc_contig_pages() interface for the allocation of
gigantic pages.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
mm/hugetlb.c | 88 +---
1 file changed, 6 insertions(+), 82 deletions(-)
diff --gi
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 <mike.krav...@oracle.com>
---
mm/page_alloc.c | 8
mm/page_isolation.c | 10 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.
level"
This patch will disable that functionality. 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
"mirror" are
> 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: <Controller#>[,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 <mike.krav...@oracle.com>
> Signed-off-by: David Rientjes <rient...@google.co
nge() fail if already
isolated" should handle this situation IF we decide to expose
alloc_gigantic_page (which I do not suggest).
--
Mike Kravetz
llocation? case you are trying to move away from. Sorry, I have not been
following development of this feature.
If you would have to create a device to accept a user buffer, could you
perhaps use the same device to create/hand out a contiguous mapping?
--
Mike Kravetz
On 02/15/2018 12:39 PM, Reinette Chatre wrote:
> On 2/14/2018 10:31 AM, Reinette Chatre wrote:
>> On 2/14/2018 10:12 AM, Mike Kravetz wrote:
>>> On 02/13/2018 07:46 AM, Reinette Chatre wrote:
>>>> Adding MM maintainers to v2 to share the new MM change (patch
h->surplus_huge_pages_node[page_to_nid(page)]++;
> }
>
> out_unlock:
I thought we had this corrected in a previous version of the patch.
My apologies for not looking more closely at this version.
FWIW,
Reviewed-by: Mike Kravetz <mike.krav...@oracle.com>
--
Mike Kravetz
On 02/12/2018 02:20 PM, Mike Kravetz wrote:
> start_isolate_page_range() is used to set the migrate type of a
> page block to MIGRATE_ISOLATE while attempting to start a
> migration operation. It is assumed that only one thread is
> attempting such an operation, and due to the li
the cgroup limit', the migration
may fail because of this.
I like your new code below as it explicitly takes reserve and cgroup
accounting out of the picture for migration. Let me think about it
for another day before providing a Reviewed-by.
--
Mike Kravetz
>> I don't think this is a bu
On 12/20/2017 04:26 PM, Andrew Morton wrote:
> On Wed, 20 Dec 2017 16:10:51 +0100 Michal Hocko <mho...@kernel.org> wrote:
>
>> On Wed 20-12-17 15:15:50, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Wed, Nov 15, 2017 at 4:13 AM, Mike Kravetz <mike.
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
to reflect this new functionality.
Signed-off-by: Mike Kravetz <mike.krav...@oracle.com>
---
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
On 07/05/2018 04:07 AM, Alexandre Ghiti wrote:
> arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures
> use the same version of huge_pte_none, so move this generic
> implementation into asm-generic/hugetlb.h.
>
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Signed-of
On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote:
> On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote:
>> The page migration code employs try_to_unmap() to try and unmap the
>> source page. This is accomplished by using rmap_walk to find all
>> vmas whe
("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
---
v2: Fixed build issue for !CONFIG_HUGETLB_PAGE and typos in comment
include/linux/hugetlb.h | 6 ++
mm/rmap.c | 21 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/h
On 08/14/2018 01:48 AM, Kirill A. Shutemov wrote:
> On Mon, Aug 13, 2018 at 11:21:41PM +0000, Mike Kravetz wrote:
>> On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote:
>>> On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote:
>>>> I am not %100 sure on the req
huge_pmd_unshare for hugetlbfs huge pages. If it is a
shared mapping it will be 'unshared' which removes the page table
entry and drops reference on PMD page. After this, flush caches and
TLB.
Signed-off-by: Mike Kravetz
---
I am not %100 sure on the required flushing, so suggestions would be
appreciated
a Tested-by :).
Just wanted to point out that it was pretty easy to hit this issue. It
was easier than the issue I am working. And, the issue I am trying to
address was seen in a real customer environment. So, I would not be
surprised to see this issue in real customer environments as well.
If you (or others) think we should go forward with these patches, I can
spend some time doing a review. Already did a 'quick look' some time back.
--
Mike Kravetz
te to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2
te to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/huge_pmd_unshare-migration-and-flushing/20180822-050255
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> #
On 08/23/2018 01:21 AM, Kirill A. Shutemov wrote:
> On Thu, Aug 23, 2018 at 09:30:35AM +0200, Michal Hocko wrote:
>> On Wed 22-08-18 09:48:16, Mike Kravetz wrote:
>>> On 08/22/2018 05:28 AM, Michal Hocko wrote:
>>>> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
&g
On 08/23/2018 05:48 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>
> OK, after burning myself when trying to be clever here it seems like
> your proposed solution is indeed simpler.
>
>> +bool huge_pmd_sharing_possible(st
On 08/23/2018 10:01 AM, Mike Kravetz wrote:
> On 08/23/2018 05:48 AM, Michal Hocko wrote:
>> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
>> [...]
>>
>> OK, after burning myself when trying to be clever here it seems like
>> your proposed solutio
that this range is flushed
if huge_pmd_unshare succeeds and unmaps a PUD_SUZE area.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 53 +++-
1 file changed, 44 insertions(+), 9 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
as suggested by
Kirill.
v3-v5: Address build errors if !CONFIG_HUGETLB_PAGE and
!CONFIG_ARCH_WANT_HUGE_PMD_SHARE
Mike Kravetz (2):
mm: migration: fix migration of huge PMD shared pages
hugetlb: take PMD sharing into account when flushing tlb/caches
include/linux/hugetlb.h | 14
;)
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 14 ++
mm/hugetlb.c| 40 +--
mm/rmap.c | 42 ++---
3 files changed, 91 insertions(+), 5 deletions(-)
On 08/24/2018 01:41 AM, Michal Hocko wrote:
> On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
>
> Acked-by: Michal Hocko
>
> One nit below.
>
> [...]
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 3103099f64fd..a73c5728e961 100644
>> --- a/mm/hugetl
;)
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
include/linux/hugetlb.h | 14 ++
mm/hugetlb.c| 40 +++
mm/rmap.c | 42 ++---
3 files changed, 93 insertions(+), 3 deletions(-)
advantage of the new routine
huge_pmd_sharing_possible() to adjust flushing ranges in the cases
where huge PMD sharing is possible. There is no copy to stable for this
patch as it has not been reported as an issue and discovered only via
code inspection.
Mike Kravetz (2):
mm: migration: fix migration
that this range is flushed if
huge_pmd_unshare succeeds and unmaps a PUD_SUZE area.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 53 +++-
1 file changed, 44 insertions(+), 9 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fd155dc52117
On 08/22/2018 02:05 PM, Kirill A. Shutemov wrote:
> On Tue, Aug 21, 2018 at 06:10:42PM -0700, Mike Kravetz wrote:
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 3103099f64fd..f085019a4724 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4555,6 +45
On 08/22/2018 05:28 AM, Michal Hocko wrote:
> On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
> [...]
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index eb477809a5c0..8cf853a4b093 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -1362,11 +1362,21 @@ static boo
On 08/27/2018 12:46 AM, Michal Hocko wrote:
> On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
>> On 08/24/2018 01:41 AM, Michal Hocko wrote:
>>> On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
>>>
>>> Acked-by: Michal Hocko
>>>
>>> One nit be
501 - 600 of 2070 matches
Mail list logo
