The steps of the technique to replace stack with hugetlbfs map are as
follows:
(1) Prepare a hugetlbfs map with the size of rlim_cur
(2) Copy the active region of the stack to the hugetlbfs map.
The range to copy is determined by reading /proc/[pid]/maps.
(3) Replace the stack map with the hugetlbfs map
The step (2) tries to copy a huge region if McKernel doesn't grow the
stack at run-time.
Change-Id: I5858c35b5c26dd0a42cccf9e3cc4c64b1a81f160
* Mapping attached part of segment is done at attach time instead of
make time to work with runtimes (e.g. OpenMPI) xpmem_make-ing the
entire user-space
* Mapping attached part of segment at attach time can be turned off by
specifying xpmem_remote_on_demand in kernel argument
* Mapping attachment chooses appropriate page-sizes, i.e., largest
allowed by memory range and segment page boundary
Fixes: a8696d8 "xpmem: Support large page attachment"
Change-Id: I44663865204036520e5f62fe22b9134ee4629f9b
make sure the caller thread holds migration queue lock with IRQs disabled
until it notifies the target CPU so that an interrupt can not deschedule
it in the middle of the request.
Change-Id: I85995018ca1e8478ccc9723985b6e8efc9c3acfb
Symptom:
A thread could call schedule() twice.
Cause:
(1) The migrator raises rescheduling flag
(2) The thread calls check_need_resched() for other
reason than the migrate IPI, e.g, response to system call
offload. And it finds that the flag is set and it's trying to
call schedule().
(3) The thread is interrupted by the migrate IPI and it finds that
the flag is set and calls schedule() in the interrupt context.
(4) The thread resumes the execution and call schedule()
Solution:
(1) Reset the rescheduling flag when checking it and it's set
(2) Set it again if it's decided not to call schedule()
Change-Id: I5376662d0b02ca4ebb29b42732e347f3b82d766d
Refs: #1400
Symptom and analysis:
runq_lock of the migration source is acquired on
the migration destination CPU.
This happens in the following steps:
(1) The thread stores value of cpu_local_var(runq_lock)
to its register when trying to perform
ihk_mc_spinlock_lock() on the lock variable.
(2) The thread takes IPI and migrates to another CPU.
(3) The thread resumes execution and acquires the wrong lock.
Solution:
* Disable interrupts before getting the value of
cpu_local_var(runq_lock)
Change-Id: Ia0ea450b97f872dd6116252537e4a79f85adfc88
Refs: #1400
Add similar protection to clear_host_pte than to set_host_vma (see #986)
Also make the page fault handler only skip taking lock if the munmap
happened on the same cpu id
Change-Id: I6d9e68e8f8905b20bb2ccfa72848e04fe6404ab6
This reverts commit 0d3ef65092.
Reason for revert: This fix causes circular dependency with memory_range manipulation and TLB flush. See #1394.
Change-Id: I4774e81ff300c199629e283e538c0a30ad0eeaae
This fixes ostest-mem_limits.001 which tries to anonymous-mmap 95% of
total memory. It reports a failure because:
(1) McKernel tries to allocate physically contiguous area and
fails
(2) It turns on demand-paging
(3) It tries to obtain a page from zeroobj and fails
(4) It allocates a new page
(5) It performs COW on the page, which is unnecessary
Change-Id: Iddf0548bb9216f9bf91fb03fa21f890e599bfdad
This fixes ostest-mem_limits.005 which tries to move brk by 95% of
total memory. It reports a failure because McKernel tries to allocate
physically contiguous area and fails.
Change-Id: I50a61cb7103fdbdbe051f0ae276a79e8e2dcdda3
Some memobjs (e.g. devobj) will not be considered 'in memobj' by
page_is_in_memobj.
Instead of trying to play whack-a-mole with the non-fileobj memobjs,
base the copy check on range's memobj and VR_PRIVATE (do not copy
MAP_SHARED mappings, so the fault handler will do the right thing™
when required)
Change-Id: Ic32cdc7766754f6559753b34845eb8c5cff6ed13
Refs: #1255
