Messages in this thread | | | Date | Wed, 8 Sep 1999 02:20:20 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: CONFIG_BIGMEM and rawio |
| |
Sorry for the late reply but I lost your email in my backlog.
On Sat, 4 Sep 1999, Manfred Spraul wrote:
>process 1: allocates memory, gets BIGMEM pages. Then it dirties a few >pages, forks new processes. >The new processes only read these pages, then kswapd tries to swap out >one of these pages.
Ok, at this point both the tasks are sharing the same page mapped as write-protected and dirty. The page-refcount is 2 now.
>When the first instance of the page is paged out, a swap cache entry is
So after the swapout one of the two process find in its VM the swap-entry instead of the wr-protected memory address.
>created in normal (i.e. not BIGMEM) memory [prepare_bigmem_swapout()]. >This copy is marked as swap cache page.
And the swap cache can be shrunk at any time. Basically the only interesting thing from this point of view is that in pte there's written the swap-entry that is pointing to the hard-disk. If there is swap-cache or not for such swap-entry it's only a matter of performances of the swapin code.
>But when the second instance is paged out, the check in mm/vmscan.c, >line 79 will not detect this >["if (PageSwapCache(page)) {" will fail] >and the page is swapped out again.
The second instance has _not_ to go into the PageSwapCache path. It can't go there because the second instance is still mapping a dirty wr-protected page that now is completly private to the second task. And that has nothing to do with the BIGMEM patch (that's true on 2.2.x as well for example).
Maybe you think that something is going wrong by duplicating the same page into two separate swap entry and having the partent using one swap-entry and the child using another separated one. But think at the fork semantic: if you are lazy you could even avoid the cow and do a plain copy-on-fork. That would be correct too. In the swapout case we are doing a double swapout and that's obviously fine since as I pointed out, you may have generated two different separated piece of memory in first place at fork time. So basically using a bounce-page to do the swapout can decrease a bit the performances because you'll duplicate the data that may be otherwise shared between the swapout-write and the other process reading it via the wr-protect pgtable at the same time, but it's safe.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |