Re: What to expect with the 2.6 VM

[Andrea Arcangeli]

On Wed, Jul 02, 2003 at 04:11:22PM -0700, William Lee Irwin III wrote:
> On Wed, Jul 02, 2003 at 03:15:51PM -0700, William Lee Irwin III wrote:
> >> What complexity? Just unmap it if you can't allocate a pte_chain and
> >> park it on the LRU.
> 
> On Thu, Jul 03, 2003 at 12:26:41AM +0200, Andrea Arcangeli wrote:
> > the complexity in munlock to rebuild what you destroyed in mlock, that's
> > linear at best (and for anonymous mappings there's no objrmap, plus
> > objrmap isn't even linear but quadratic in its scan [hence the problem
> > with it], though in practice it would be normally faster than the linear
> > of the page scanning ;)
> 
> Computational complexity; okay.
> 
> It's not quadratic; at each munlock(), it's not necessary to do

yes, as said above it's linear with the number of virtual pages mapped
unless you use the objrmap to rebuild rmap.

> anything more than:

is this munmap right?

> 
> for each page this mlock()'er (not _all_ mlock()'ers) maps of this thing
> 	grab some pagewise lock
> 	if pte_chain allocation succeeded
> 		add pte_chain

allocated sure, but it has no information yet, you dropped the info in
mlock

> 	else
> 		/* you'll need to put anon pages in swapcache in mlock() */
> 		unmap the page

how to unmap? there's no rmap. also there may not be swap at all to
allocate swapcache from

> 	decrement lockcount
> 	if lockcount vanished
> 	park it on the LRU
> 	drop the pagewise lock
> 
> Individual mappers whose mappings are not mlock()'d add pte_chains when
> faulting the things in just like before.

Tell me how you reach the pagetable from munlock to do the unmap. If you
can reach the pagetable, the unmap isn't necessary and you only need to
rebuild the rmap. and if you can reach the pagetable efficiently w/o
rmap, it means rmap is useless in the first place.

Andrea