Re: [PATCH 2/2] mm: THP page cache support for ppc64

From: Kirill A. Shutemov
Date: Fri Nov 11 2016 - 11:29:16 EST


On Fri, Nov 11, 2016 at 05:42:11PM +0530, Aneesh Kumar K.V wrote:
> "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes:
>
> > On Mon, Nov 07, 2016 at 02:04:41PM +0530, Aneesh Kumar K.V wrote:
> >> @@ -2953,6 +2966,13 @@ static int do_set_pmd(struct fault_env *fe, struct page *page)
> >> ret = VM_FAULT_FALLBACK;
> >> page = compound_head(page);
> >>
> >> + /*
> >> + * Archs like ppc64 need additonal space to store information
> >> + * related to pte entry. Use the preallocated table for that.
> >> + */
> >> + if (arch_needs_pgtable_deposit() && !fe->prealloc_pte)
> >> + fe->prealloc_pte = pte_alloc_one(vma->vm_mm, fe->address);
> >> +
> >
> > -ENOMEM handling?
>
> How about
>
> if (arch_needs_pgtable_deposit() && !fe->prealloc_pte) {
> fe->prealloc_pte = pte_alloc_one(vma->vm_mm, fe->address);
> if (!fe->prealloc_pte)
> return VM_FAULT_OOM;
> }
>
>
>
> >
> > I think we should do this way before this point. Maybe in do_fault() or
> > something.
>
> doing this in do_set_pmd keeps this closer to where we set the pmd. Any
> reason you thing we should move it higher up the stack. We already do
> pte_alloc() at the same level for a non transhuge case in
> alloc_set_pte().

I vaguely remember Hugh mentioned deadlock of allocation under page-lock vs.
OOM-killer (or something else?).

If the deadlock is still there it would be matter of making preallocation
unconditional to fix the issue.

But what you propose about doesn't make situation any worse. I'm fine with
that.

--
Kirill A. Shutemov