Re: What to expect with the 2.6 VM

On Thu, Jul 03, 2003 at 01:30:14AM +0200, Andrea Arcangeli wrote:

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

I was describing munlock(); munmap() would do the same except not even
bother trying to allocate the pte_chains and always unmap it from the
processes whose mappings are being fiddled with.


On Wed, Jul 02, 2003 at 04:11:22PM -0700, William Lee Irwin III wrote:

quoted

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

On Thu, Jul 03, 2003 at 01:30:14AM +0200, Andrea Arcangeli wrote:

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

We have the information because I'm describing this as part of doing a
pagetable walk over the mlock()'d area we're munlock()'ing.


On Wed, Jul 02, 2003 at 04:11:22PM -0700, William Lee Irwin III wrote:

quoted

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

On Thu, Jul 03, 2003 at 01:30:14AM +0200, Andrea Arcangeli wrote:

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

That doesn't matter; it only has to have an entry in swapper_space's
radix tree. But this actually could mean trouble since things currently
assume swap is preallocated for each entry in swapper_space's page_tree.

Which is fine; just revert to the old chaining semantics for mlock()'d
pages with PG_anon high.


On Wed, Jul 02, 2003 at 04:11:22PM -0700, William Lee Irwin III wrote:

quoted

	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.

On Thu, Jul 03, 2003 at 01:30:14AM +0200, Andrea Arcangeli wrote:

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.

This algorithm occurs during a pagetable walk of the process we'd unmap
it from; we don't unmap it from all processes, just the current one, and
allow it to take minor faults.


-- wli
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>