Hi Andrea,
On 02/11/2017 21:08, Andrea Arcangeli wrote:
> On Thu, Nov 02, 2017 at 06:25:11PM +0100, Laurent Dufour wrote:
>> I think there is some memory barrier missing when the VMA is modified so
>> currently the modifications done in the VMA structure may not be written
>> down at the time the
On Thu, Nov 02, 2017 at 06:25:11PM +0100, Laurent Dufour wrote:
> I think there is some memory barrier missing when the VMA is modified so
> currently the modifications done in the VMA structure may not be written
> down at the time the pte is locked. So doing that change will also requires
> to ca
On 02/11/2017 16:16, Laurent Dufour wrote:
> Hi Andrea,
>
> Thanks for reviewing this series, and sorry for the late answer, I took few
> days off...
>
> On 26/10/2017 12:18, Andrea Arcangeli wrote:
>> Hello Laurent,
>>
>> Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea...@intel.com> shows
>> si
Hi Andrea,
Thanks for reviewing this series, and sorry for the late answer, I took few
days off...
On 26/10/2017 12:18, Andrea Arcangeli wrote:
> Hello Laurent,
>
> Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea...@intel.com> shows
> significant slowdown even for brk/malloc ops both single and
>
Hello Laurent,
Message-ID: <7ca80231-fe02-a3a7-84bc-ce81690ea...@intel.com> shows
significant slowdown even for brk/malloc ops both single and
multi threaded.
The single threaded case I think is the most important because it has
zero chance of getting back any benefit later during page faults.
C
The VMA sequence count has been introduced to allow fast detection of
VMA modification when running a page fault handler without holding
the mmap_sem.
This patch provides protection against the VMA modification done in :
- madvise()
- mremap()
- mpol_rebind_policy()
