lkml.org 
[lkml]   [1999]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.120 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site