used before. Could this possibly
introduce inconsistencies in their use of READ_ONCE? To be honest, I
am not very good at identifying any possible issues this could cause.
However, it does seem possible.
Will was nervous about dropping this from arm64. I'm just a little nervous
about adding it to other architectures.
--
Mike Kravetz
Cc: Palmer Dabbelt
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> C
, but that is pretty
straight forward.
I'm guessing this may not reproduce easily. To help reproduce, you could
change the
#define FALLOCATE_ITERATIONS 10
in .../libhugetlbfs/tests/fallocate_stress.c to a larger number to force
the stress test to run longer.
--
Mike Kravetz
ump
> perspective. The trick part is exactly preventing the sysctl to get applied
> heh
>
Please do let us know if this can be done in tooling.
I am not opposed to the approach taken in your v2 patch as it essentially
uses the hugepages_supported() functionality that exists today. However,
it seems that other distros have ways around this issue. As such, I would
prefer if the issue was addressed in the tooling.
--
Mike Kravetz
On 10/15/19 4:37 PM, Mike Kravetz wrote:
> On 10/15/19 3:50 AM, Michal Hocko wrote:
>> On Tue 15-10-19 11:01:12, Piotr Sarna wrote:
>>> With hugetlbfs, a common pattern for mapping anonymous huge pages
>>> is to create a temporary file first.
>>
>> Real
retry_locked;
> }
I know that I suggested allocating the worst case number of entries, but this
is going to be too much of a hit for existing hugetlbfs users. It is not
uncommon for DBs to have a shared areas in excess of 1TB mapped by hugetlbfs.
With this new scheme, the above while loop will allocate over a half million
file region entries and end up only using one.
I think we need to step back and come up with a different approach. Let me
give it some more thought before throwing out ideas that may waste more of
your time. Sorry.
--
Mike Kravetz
On 5/10/20 9:02 PM, Anshuman Khandual wrote:
> On 05/09/2020 03:39 AM, Mike Kravetz wrote:
>> On 5/7/20 8:07 PM, Anshuman Khandual wrote:
>> I know you made this change in response to Will's comment. And, since
>> changes were made to consistently use READ_ONCE in arm64 co
On 5/10/20 8:14 PM, Anshuman Khandual wrote:
> On 05/09/2020 03:52 AM, Mike Kravetz wrote:
>> On 5/7/20 8:07 PM, Anshuman Khandual wrote:
>>
>> Did you try building without CONFIG_HUGETLB_PAGE defined? I'm guessing
>
> Yes I did for multiple platforms (s390, ar
Cc: Palmer Dabbelt
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: "David S. Miller"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
On 5/12/20 8:04 AM, Miklos Szeredi wrote:
> On Tue, Apr 7, 2020 at 12:06 AM Mike Kravetz wrote:
>> On 4/5/20 8:06 PM, syzbot wrote:
>>
>> The routine is_file_hugepages() is just comparing the file ops to huegtlbfs:
>>
>> if (file->f_op == _file_operat
*/
>> + if (mm->get_unmapped_area == arch_get_unmapped_area_topdown)
>> + return hugetlb_get_unmapped_area_topdown(file, addr, len,
>> + pgoff, flags);
>> + return hugetlb_get_unmapped_area_bottomup(file, addr, len,
>
On 5/18/20 4:12 AM, Miklos Szeredi wrote:
> On Sat, May 16, 2020 at 12:15 AM Mike Kravetz wrote:
>> Any suggestions on how to move forward? It seems like there may be the
>> need for a real_file() routine? I see a d_real dentry_op was added to
>> deal with this issue fo
On 6/4/20 2:16 AM, Miklos Szeredi wrote:
> On Thu, May 28, 2020 at 11:01 PM Mike Kravetz wrote:
>>
>> Well yuck! get_unmapped_area is not part of mm_struct if !CONFIG_MMU.
>>
>> Miklos, would adding '#ifdef CONFIG_MMU' around the overlayfs code be too
>> ugly f
knew adding a file op for this was overkill and was looking for other
suggestions.
--
Mike Kravetz
t;>
>> As I've said I would _prefer_ simplicity over "correctness" if it is only
>> partial and hard to reason about from the userspace experience but this
>> is not something I would _insist_ on. If Mike as a maintainer of the
>> code is ok with that then I will
ome functions like
> hwpoison_user_mappings() and identify_page_state(), so they should properly
> handle 4kB page, thp, and hugetlb.
>
> Signed-off-by: Naoya Horiguchi
> Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
--
Mike Kravetz
Signed-off-by: Naoya Horiguchi
Reviewed-by: Mike Kravetz
--
Mike Kravetz
there would be no need for such
a check in the allocation code (except for sanity cheching).
Thoughts? I just cleaned up the parsing code and could make such a change
quite easily.
--
Mike Kravetz
emalloc_nocma_{save,restore}
> to exclude CMA memory rather than manually clearing __GFP_MOVABLE. And,
> this patch also makes the deque function on hugetlb CMA aware. In the
> deque function, CMA memory is skipped if PF_MEMALLOC_NOCMA flag is set
> by memalloc_nocma_{save,restore}.
_reserve when we reserve CMA.
--
Mike Kravetz
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fab4485b9e52..92cb882cf287 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -46,6 +46,7 @@ unsigned int default_hstate_idx;
struct hstate hstates[HUGE_MAX_HSTATE];
static struct cma *hugetlb_cma[MAX_
On 7/9/20 4:45 PM, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-----
>> From: Mike Kravetz [mailto:mike.krav...@oracle.com]
>> Sent: Friday, July 10, 2020 6:58 AM
>> To: Song Bao Hua (Barry Song) ; Roman
>> Gushchin
>> Cc: Andrew Mo
reservation and CMA leak.
>
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages
> using cma")
> Cc: Mike Kravetz
> Cc: Jonathan Cameron
> Acked-by: Roman Gushchin
> Signed-off-by: Barry Song
Thank you!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 28
mm/hugetlb.c | 23 ---
2 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index ef5313f9c78f..b4bb82815dd4 100644
--- a/fs
to always take i_mmap_rwsem. These are not as performance
sensitive.
Reported-by: kernel test robot
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 96 ++--
1 file changed, 63 insertions(+), 33 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
[1] https://lore.kernel.org/lkml/20200622005551.GK5535@shao2-debian
Mike Kravetz (3):
Revert: "hugetlbfs: Use i_mmap_rwsem to address page fault/truncate
race"
hugetlbfs: Only take i_mmap_rwsem when sharing is possible
huegtlbfs: handle page fault/truncate races
fs/hug
as necessary.
File truncation (remove_inode_hugepages) needs to handle page mapping
changes before locking the page. This could happen if page was added
to page cache and later backed out in fault processing.
Reported-by: kernel test robot
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 41
to smaller than PMD_SIZE.
Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
synchronization")
Cc: sta...@kernel.org
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 57
case
of PMD sharing. I'm afraid a regression is unavoidable in that case.
I'll put together a patch.
--
Mike Kravetz
.
Suggested-by: Al Viro
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c| 7 +++
fs/io_uring.c | 2 +-
include/linux/fs.h | 3 +++
include/linux/hugetlb.h | 10 --
include/linux/shm.h | 5 -
ipc/shm.c | 34
sult in the BUG as shown in [1].
[1] https://lore.kernel.org/linux-mm/b4684e05a2968...@google.com/
Reported-by: syzbot+d6ec23007e951dadf...@syzkaller.appspotmail.com
Signed-off-by: Miklos Szeredi
Signed-off-by: Mike Kravetz
---
fs/overlayfs/file.c | 21 +
1 file cha
On 6/11/20 6:58 PM, Al Viro wrote:
> On Thu, Jun 11, 2020 at 05:46:43PM -0700, Mike Kravetz wrote:
>> The routine is_file_hugepages() checks f_op == hugetlbfs_file_operations
>> to determine if the file resides in hugetlbfs. This is problematic when
>> the file is on a union
On 5/20/20 4:20 AM, Miklos Szeredi wrote:
> On Tue, May 19, 2020 at 2:35 AM Mike Kravetz wrote:
>>
>> On 5/18/20 4:41 PM, Colin Walters wrote:
>>>
>>> On Tue, May 12, 2020, at 11:04 AM, Miklos Szeredi wrote:
>>>
>>>>> However, in this
On 5/17/20 6:20 PM, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> It's not performance sensitive function. Move it to .c.
> This is a preparation step for future change.
>
> Signed-off-by: Joonsoo Kim
Agreed, this is not performance sensitive and can be moved.
Acke
; - preferred_nid, nodemask);
> + if (PageHuge(page)) {
> + struct hstate *h = page_hstate(page);
I assume the removal of compound_head(page) was intentional? Just asking
because PageHuge will look at head page while page_hstate will not. So,
if passed a non-head page things could go bad.
--
Mike Kravetz
alling sequences.
However, it appears that node (preferred_nid) is always set to something
other than NUMA_NO_NODE in those callers.
It obviously makes sense to add the field to guarantee no changes to
functionality while making the conversions. However, it it is not really
necessary then
e side
> to get better result.
>
> Signed-off-by: Joonsoo Kim
Thank you!
Avoiding CMA works much better with this new skip_cma field.
Acked-by: Mike Kravetz
--
Mike Kravetz
lags as is done in the existing code does not bother me
too much, but that is just my opinion. Adding __gfp_mask for modifications
is fine with me if others think it is a good thing.
Does dequeue_huge_page_vma() need to be modified so that it will set
ac.__gfp_mask before calling dequeue_huge_page_nodemask()?
-
EM if users set name parameter as NULL.
>
> Cc: Roman Gushchin
> Signed-off-by: Barry Song
Thank you
Reviewed-by: Mike Kravetz
--
Mike Kravetz
>
> Cc: Roman Gushchin
> Signed-off-by: Barry Song
Thank you
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> parameter is preceded by an invalid hugepagesz parameter, it will
> be ignored.
> -default_hugepagesz - Specify the default huge page size. This parameter can
> +default_hugepagesz
> + pecify the default huge page size. This parameter can
Oops, should be 'Specify'
not care about the combination
> of hugetlbfs with any of the above.
>
> overlayfs support of mmap is not as good as one might hope.
> overlayfs.rst says:
> "If a file residing on a lower layer is opened for read-only and then
> memory mapped with MAP_SHARED, then subsequent changes to
> the file are not reflected in the memory mapping."
>
> So if I were you, I wouldn't go trying to fix overlayfs-huguetlb interop...
Thanks again,
I'll look at something as simple as s_stack_depth.
--
Mike Kravetz
ologies!!!
I reviewed my testing and found that it was incorrectly writing to the
lower filesystem. Writing to any file in the union will fail.
--
Mike Kravetz
On 6/15/20 12:53 AM, Miklos Szeredi wrote:
> On Sat, Jun 13, 2020 at 9:12 PM Mike Kravetz wrote:
>> On 6/12/20 11:53 PM, Amir Goldstein wrote:
>>>
>>> The simplest thing for you to do in order to shush syzbot is what procfs
>>> does:
>>> /*
&g
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/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/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
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
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() --
On 2/12/19 2:14 PM, Mike Kravetz wrote:
>
> Hugetlb pages can also be leaked at migration time if the pages are
> associated with a file in an explicitly mounted hugetlbfs filesystem.
> For example, a test program which hole punches, faults and migrates
> pages in such a f
On 1/14/19 7:35 AM, Steven Sistare wrote:
> On 1/11/2019 6:28 PM, Mike Kravetz wrote:
>> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote:
>>> On Fri, Jan 11, 2019 at 08:10:03PM +, Mike Kravetz wrote:
>>>> At LPC last year, Boaz Harrosh asked why he had to 'j
On 1/15/19 12:24 AM, Kirill A. Shutemov wrote:
> On Mon, Jan 14, 2019 at 10:54:45AM -0800, Mike Kravetz wrote:
>> On 1/14/19 7:35 AM, Steven Sistare wrote:
>>> On 1/11/2019 6:28 PM, Mike Kravetz wrote:
>>>> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote:
>>&g
91.658122] do_mount+0x11f0/0x1640
> [ 91.658125] ksys_mount+0xc0/0xd0
> [ 91.658129] __arm64_sys_mount+0xcc/0xe4
> [ 91.658137] el0_svc_handler+0x28c/0x338
> [ 91.681740] el0_svc+0x8/0xc
>
> Fixes: 2284cf59cbce ("hugetlbfs: Convert to fs_context")
> Signed-off-by:
that runtime allocation of gigantic pages is not supported,
> one can still allocate boottime gigantic pages if the architecture supports
> it.
>
> Signed-off-by: Alexandre Ghiti
Thank you for doing this!
Reviewed-by: Mike Kravetz
> --- a/include/linux/gfp.h
> +++ b/i
: 290408d4a250 ("hugetlb: hugepage migration core")
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/inode.c | 10 ++
mm/migrate.c | 10 --
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 32
or normal base pages: not too well :). Once base page support is
finalized, I suspect I will be involved in hugetlbfs support.
--
Mike Kravetz
On 1/30/19 1:14 PM, Mike Kravetz wrote:
> Files can be created and mapped in an explicitly mounted hugetlbfs
> filesystem. If pages in such files are migrated, the filesystem
> usage will not be decremented for the associated pages. This can
> result in mmap or page allocat
On 2/7/19 6:31 PM, Naoya Horiguchi wrote:
> On Thu, Feb 07, 2019 at 10:50:55AM -0800, Mike Kravetz wrote:
>> On 1/30/19 1:14 PM, Mike Kravetz wrote:
>>> +++ b/fs/hugetlbfs/inode.c
>>> @@ -859,6 +859,16 @@ static int hugetlbfs_migrate_page(struct address_spac
hys.
Although, it is potentially used in gather_bootmem_prealloc(). It appears
powerpc used this field at one time, but no longer does.
Am I missing something?
Not an issue with this patch, rather existing code. I'd prefer not to do
the memset() "just to be safe". Un
>> initialize the rest explicitly already.
>
> Forgot to mention that after that is addressed you can add
> Acked-by: Michal Hocko
Cannon,
How about if you make this change suggested by Michal, and I will submit
a separate patch to revert the patch which added the phys field to
huge_bootmem_page structure.
FWIW,
Reviewed-by: Mike Kravetz
--
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
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
er 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, Ying"
> Suggest
emory 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, and the time spent in user sp
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: "Huang, Ying"
> Suggested-
ter the page fault under heavy cache contention.
>
> Signed-off-by: "Huang, Ying"
Reviewed-by: Mike Kravetz
--
Mike Kravetz
> Cc: Mike Kravetz
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: Andrea Arcangeli
> Cc: "Kirill A. Shutemov"
> Cc: Andi Klee
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
above. With the
suggested changes, I think this is OK for huge pages. However, it seems
that setting HWPoison on a in use non-huge page could cause issues?
While looking at the code, I noticed this comment in __get_any_page()
/*
* When the target page is a free hugepage, just remove it
* from free hugepage list.
*/
Did that apply to some code that was removed? It does not seem to make
any sense in that routine.
--
Mike Kravetz
On 07/17/2018 06:28 PM, Naoya Horiguchi wrote:
> On Tue, Jul 17, 2018 at 01:10:39PM -0700, Mike Kravetz wrote:
>> It seems that soft_offline_free_page can be called for in use pages.
>> Certainly, that is the case in the first workflow above. With the
>> suggested change
On 12/17/18 2:25 AM, Aneesh Kumar K.V wrote:
> On 12/4/18 1:38 AM, Mike Kravetz wrote:
>> hugetlbfs page faults can race with truncate and hole punch operations.
>> Current code in the page fault path attempts to handle this by 'backing
>> out' operations if we encounter t
ill Tkhai
Thanks for cleaning this up!
Reviewed-by: Mike Kravetz
--
Mike Kravetz
On 12/17/18 10:42 AM, Mike Kravetz wrote:
> On 12/17/18 2:25 AM, Aneesh Kumar K.V wrote:
>> On 12/4/18 1:38 AM, Mike Kravetz wrote:
>>>
>>> Instead of writing the required complicated code for this rare
>>> occurrence, just eliminate the race. i_mma
gt;
>> Signed-off-by: Yongkai Wu
>> Acked-by: Michal Hocko
>> Acked-by: Mike Kravetz
Thank you for fixing the formatting and commit message.
Adding Andrew on so he can add to his tree as appropriatre. Also Cc'ing Michal.
>> ---
>> mm/hugetlb.c | 5 +++--
>>
ation to the
change log (commit message) and fix the formatting of the patch.
Can you tell us more about the root cause of your issue? What was the issue?
How could you reproduce it? How did you solve it?
--
Mike Kravetz
On 10/25/18 5:42 PM, Naoya Horiguchi wrote:
> Hi Mike,
>
> On Tue, Oct 23, 2018 at 09:50:53PM -0700, Mike Kravetz wrote:
>> Now, anopther task truncates the hugetlbfs file. As part of truncation,
>> it unmaps everyone who has the file mapped. If a task has a shared p
On 12/18/18 2:10 PM, Andrew Morton wrote:
> On Mon, 17 Dec 2018 16:17:52 -0800 Mike Kravetz
> wrote:
>
>> ...
>>
>>> As you suggested in a comment to the subsequent patch, it would be better to
>>> combine the patches and remove the dead code
7-1-mike.krav...@oracle.com
Comments made by Naoya were addressed.
Mike Kravetz (2):
hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization
hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
fs/hugetlbfs/inode.c | 50 +
mm/hugetlb.c
of huge_pte_alloc continue to hold the semaphore until finished with
the ptep.
- i_mmap_rwsem is held in write mode whenever huge_pmd_unshare is called.
Cc:
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c
. Remove the dead code
and expand comments to explain reasoning. Similarly, checks for races
with truncation in the page fault path can be simplified and removed.
Cc:
Fixes: ebed4bfc8da8 ("hugetlb: fix absurd HugePages_Rsvd")
Signed-off-by: Mike Kravetz
---
fs/hugetlbfs/in
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
;)
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
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:
> #
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
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
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/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
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
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
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
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
1301 - 1400 of 2070 matches
Mail list logo
