Re: Allow migration of mlocked page?

[Peter Zijlstra <peterz@infradead.org>]

On Mon, 2012-05-14 at 09:01 -0500, Christoph Lameter wrote:
> On Mon, 14 May 2012, Peter Zijlstra wrote:
> 
> > I'd say go for it, I've been telling everybody who would listen that
> > mlock() only means no major faults for a very long time now.
> 
> We could introduce a new page flag PG_pinned (it already exists for Xen)
> that would mean no faults on the page?
> 
> The situation with pinned pages is not clean right now because page count
> increases should only signal temporary references to a page but subsystems
> use an elevated page count to pin pages for good (f.e. Infiniband memory
> registration). The reclaim logic has no way to differentiate between a
> pinned page and a temporary reference count increase for page handling.
> 
> Therefore f.e. the page migration logic will repeatedly try to move the
> page and always fail to account for all references.
> 
> A PG_pinned could allow us to make that distinction to avoid overhead in
> the reclaim and page migration logic and also we could add some semantics
> that avoid page faults.

Either that or a VMA flag, I think both infiniband and whatever new
mlock API we invent will pretty much always be VMA wide. Or does the
infinimuck take random pages out? All I really know about IB is to stay
the #$%! away from it [as Mel recently learned the hard way] :-)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>