On Thu, Dec 13, 2018 at 12:59:42PM +0300, Kirill A. Shutemov wrote:
> On Thu, Dec 13, 2018 at 01:15:10PM +0800, Peter Xu wrote:
> > When splitting a huge migrating PMD, we'll transfer all the existing
> > PMD bits and apply them again onto the small PTEs. However we are
> > fetching the bits uncon
On Thu, Dec 13, 2018 at 01:15:10PM +0800, Peter Xu wrote:
> When splitting a huge migrating PMD, we'll transfer all the existing
> PMD bits and apply them again onto the small PTEs. However we are
> fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
> or pmd_yound() while actually
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index f2d19e4fe854..aebade83cec9 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2145,23 +2145,25 @@ static void __split_huge_pmd_locked(struct
> vm_area_struct *vma, pmd_t *pmd,
>*/
> old_pmd = pmdp_invalidate(vm
On Thu, Dec 13, 2018 at 8:15 AM Peter Xu wrote:
>
> When splitting a huge migrating PMD, we'll transfer all the existing
> PMD bits and apply them again onto the small PTEs. However we are
> fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
> or pmd_yound() while actually they d
When splitting a huge migrating PMD, we'll transfer all the existing
PMD bits and apply them again onto the small PTEs. However we are
fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
or pmd_yound() while actually they don't make sense at all when it's
a migration entry. Fix th
5 matches
Mail list logo