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:
>> 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:
>> 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:
>> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/