* 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
We do not need two debug.h files.
Take Fujitsu's STATIC_ASSERT over BUILD_BUG_ON because it is more used
Change-Id: If04c17fbb7406ab15fe86267fed8d6da460cec62
Fujitsu: POSTK_DEBUG_ARCH_DEP_9
Don't ask me why this shares POSTK_DEBUG_ARCH_DEP_50 with the ksym lookups...
Change-Id: Ic3db2cd77ca88be361cefec85d8ed9deb21ffcd8
Fujitsu: POSTK_DEBUG_ARCH_DEP_50
* Merge cd7ab307fae9bc8aa49d23b32becf37368a1603e
* Merge commit is changed to one commit for gerrit
Change-Id: I75f0f4cf6b8b3286284638ac2c7816c5257551e4
