Re: [RFC] Changing COW detection to be memory hotplug friendly

From: IWAMOTO Toshihiro
Date: Thu Feb 10 2005 - 03:00:24 EST


At Tue, 8 Feb 2005 16:26:26 +0000 (GMT),
Hugh Dickins wrote:
>
> On Mon, 7 Feb 2005, Hugh Dickins wrote:
> > On Thu, 3 Feb 2005, IWAMOTO Toshihiro wrote:
> > > The current implementation of memory hotremoval relies on that pages
> > > can be unmapped from process spaces. After successful unmapping,
> > > subsequent accesses to the pages are blocked and don't interfere
> > > the hotremoval operation.
> > >
> > > However, this code
> > >
> > > if (PageSwapCache(page) &&
> > > page_count(page) != page_mapcount(page) + 2) {
> > > ret = SWAP_FAIL;
> > > goto out_unmap;
> > > }
> >
> > Yes, that is odd code. It would be nice to have a solution without it.
> >
> > > in try_to_unmap_one() prevents unmapping pages that are referenced via
> > > get_user_pages(), and such references can be held for a long time if
> > > they are due to such as direct IO.
> > > I've made a test program that issues multiple direct IO read requests
> > > against a single read buffer, and pages that belong to the buffer
> > > cannot be hotremoved because they aren't unmapped.
> >
> > ....
> >
> > I was hoping to append my own patch to this response, but I haven't
> > got it working right yet (swap seems too full). I hope tomorrow,
> > but thought I'd better not delay these comments any longer.
>
> Seems it was okay after all, I got confused by an unrelated issue.
> Here's what I had in mind, what do you think? Does it indeed help
> with your problem? I'm copying Andrea because it was he who devised
> that fix to the get_user_pages issue, and also (I think, longer ago)
> can_share_swap_page itself.

I've tested with linux-2.6.10-rc2-mm3 + my hotremoval patch, and it
passed hotremoval tests including the direct IO related one.

Thanks.

> --- 2.6.11-rc3-mm1/mm/memory.c 2005-02-05 07:09:40.000000000 +0000
> +++ linux/mm/memory.c 2005-02-07 19:50:47.000000000 +0000

--
IWAMOTO Toshihiro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/