Re: swap cache

Prasun Kapoor (prasun@wipinfo.soft.net)
Fri, 18 Dec 1998 13:01:14 -0500 (GMT)

> > This to me looks like a cleaner implemetation, where fork takes care of
> > COW functionality and hence sharing of clean swap pages.
>
> That has nothing to do with it. Think about it for a minute. fork() is
> how COW-shared pages are generated in the first place. Yep, we do
> that.
>
> What then happens if one of the related processes starts to page stuff
> in _after_ the sharing has been set up in swap? What happens if we
> start to swap in-core COW stuff out _after_ the sharing has been set up
> in memory?
> Umm, you're telling me that fork will take care of this clean page
> sharing for me? I don't think so: fork is a dim and distant memory by
> this point. The swap cache relates physical pages in memory to swap
> pages on disk. It is the mechanism by which we maintain that clean
> sharing you want, even after the fork, and even if some processes still
> refer to the original page on swap but others have paged the data back
> into memory.

Two things here: I never said swap cache in unnecessary! It is the only
way you prevent yrself from going to disk when the page is ALREADY in
memory. (Though I dont understand the need for a seperate terminology for
it. Every file that is mmap()ed has a list of its "in memory" pages
maintained in its vnode page list and also in the global vnode-offset hash
list. In this respect the vnode page list for swap vnode is the swap
cache )

All segments that require sharing (stack, heap et all) are MAP_PRIVATE.
What fork() does is that it TURNS OFF write permission for all these
addresses on the PAGE TABLE ( via hat_chgprot() ) for both parent and
child. Now if either child or parent faults on any of these address
ranges, ( as you say much after fork()) they get a fault. This fault is a
COW fault and results in a new swap allocation for the process that
faulted and a new page. The orignal page remains clean.

>No, we can't do that. The swap cache allows us to have multiple
>processes sharing the same page of swap (think of a process which gets
>partially swapped out and which then forks). The whole point of loading
>the pages read-only in the first instance is so that if we do have such
>sharing of the page, any attempt by one process to write to the page
>causes a page fault and gives that process a new, private copy of the
>page.

The pages are not loaded RO in the first instance. Their page table
entries are made RO at fork() itself thus taking care of any future
writes.

> As I've just explained, that is wishful thinking. We still have to
> maintain the sharing beyond fork(), while potential sharers of the page
> swap stuff pages and out independently of each other.

Potential sharers can swap pages IN independently of each other ( and in
this case page goes to the vnode-offset hash list or as you say swap cache
to be found by others). But processes cannot swap pages OUT independently
of each other. Swap out is done on a global scale and all referencing PTEs
are invalidated when that happens.

And this is why I said the dirty bit is the only things that decides
whether a page needs to go to disk or not.

prasun

_____________________________________________________________________________
"If seven maids with seven mops, Swept it for half a
Prasun Kapoor year, do you suppose" the Walrus said, "That they
Wipro Infotech Ltd. could get it clear"."I doubt it" said the Carpenter,
Ph. 2241730 Extn. 3312 and shed a bitter tear

"Through the looking glass and what alice found
there" - Alice in Wonderland -

-
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/