[lkml]   [1998]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: swap cache

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

    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

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


    "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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.023 / U:5.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site