[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110201160932.GY16981@random.random>
Date: Tue, 1 Feb 2011 17:09:32 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
Cc: Johannes Weiner <hannes@...xchg.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Michael J Wolf <mjwolf@...ibm.com>
Subject: Re: [RFC][PATCH 5/6] teach smaps_pte_range() about THP pmds
On Tue, Feb 01, 2011 at 07:02:30AM -0800, Dave Hansen wrote:
> On Tue, 2011-02-01 at 11:11 +0100, Johannes Weiner wrote:
> > On Mon, Jan 31, 2011 at 04:34:03PM -0800, Dave Hansen wrote:
> > > + if (pmd_trans_huge(*pmd)) {
> > > + if (pmd_trans_splitting(*pmd)) {
> > > + spin_unlock(&walk->mm->page_table_lock);
> > > + wait_split_huge_page(vma->anon_vma, pmd);
> > > + spin_lock(&walk->mm->page_table_lock);
> > > + goto normal_ptes;
> > > + }
> > > + smaps_pte_entry(*(pte_t *)pmd, addr, HPAGE_SIZE, walk);
> > > + return 0;
> > > + }
> > > +normal_ptes:
> > > split_huge_page_pmd(walk->mm, pmd);
> >
> > This line can go away now...?
>
> I did this because I was unsure what keeps khugepaged away from the
> newly-split ptes between the wait_split_huge_page() and the
> reacquisition of the mm->page_table_lock. mmap_sem, perhaps?
Any of mmap_sem read mode, PG_lock and anon_vma_lock keeps khugepaged
away.
> Looking at follow_page() and some of the other wait_split_huge_page(),
> it looks like this is unnecessary.
When wait_split_huge_page returns after the pmd was splitting, the pmd
can't return huge under you as long as you hold any of the above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists