[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <00000140828ea17e-d69af79a-1d8e-4df2-9513-492df5e00afc-000000@email.amazonses.com>
Date: Thu, 15 Aug 2013 15:18:40 +0000
From: Christoph Lameter <cl@...two.org>
To: Minchan Kim <minchan@...nel.org>
cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
k.kozlowski@...sung.com,
Seth Jennings <sjenning@...ux.vnet.ibm.com>,
Mel Gorman <mgorman@...e.de>, guz.fnst@...fujitsu.com,
Benjamin LaHaise <bcrl@...ck.org>,
Dave Hansen <dave.hansen@...el.com>, lliubbo@...il.com,
aquini@...hat.com, Rik van Riel <riel@...hat.com>
Subject: Re: [RFC 0/3] Pin page control subsystem
On Thu, 15 Aug 2013, Minchan Kim wrote:
> Now mlock pages could be migrated in case of CMA so I think it's not a
> big problem to migrate it for other cases.
> I remember You and Peter argued what's the mlock semainc of pin POV
> and as I remember correctly, Peter said mlock doesn't mean pin so
> we could migrate it but you didn't agree. Right?
mlock means it can be migrated. Pinning is currently done by increasing
the page count. Migration will be attempted but it will fail since the
references cannot be all removed. Peter proposed that mlock would work
like pinning so that a migration of the page would not be attempted.
My concern is not only about migration but about a general way of pinning
pages. Having mlock and pinning with different semantics is already an
issue as the conversation with Peter brought out. Now we are
adding yet another way that pinning is used.
--
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