Re: swap cache

Prasun Kapoor (prasun@wipinfo.soft.net)
Sat, 19 Dec 1998 17:17:15 -0500 (GMT)


> The same arrangement _is_ used. The swap cache used to be a small
> extra side-function in the VM, but the current swap cache uses the
> page cache mechanisms, with pages indexed on a reserved swapper_inode
> for swap pages. The term "swap cache" refers to that subset of pages,
> and the only reason there is a separate term for it is that the old VM
> did have a separate mechanism here.
>
> Deep inside the VM, the routes we take when faulting these different
> types of page are sometimes very different from each other, and at that
> level, the swap cache is definitely a quite distinct beast.

Yup, that explains it.

> I wrote the swap cache. I believe I know what a copy-on-write fault is.

oops:)

> They _are_ loaded RO in the first instance. "Loaded" from disk, not
> "generated" when the original data is created. I'm talking about
> physical pages in memory. When we read in ("load") a page from swap,
> then we mark that newly-swapped-in page readonly. There are several
> reasons for this:

I have a doubt here. It is the PTE that makes a process's access to a page
RO. If the PTE is marked RO ( even though there is no physical page
corresponding to it), when a process tries to read it, its a normal fault
to bring the page into memroy and also swap cache. And when it writes to
it, it faults again. The fault routine sees that the mapping is
MAP_PRIVATE with write access and the fault is a WRITE fault and hence
creates a new page.

In this context what exactly is meant by loading a page in RO mode, when
the PTE for it is already marked RO?

> > 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.
>
> Wrong. You've been looking at other Unix source code or books about
> other Unixes. Linux does not work this way. Linux supports a number of
> VM optimisations not found elsewhere, such as mremap() to map an
> existing set of pages elsewhere in the VM (giving kernel support to
> realloc(3), for example). This means that a a shared anonymous page may
> be found at different VAs in different processes. It is distinctly
> non-trivial to find all ptes referencing a given physical page in the

Ummmm I dont think I'd agree. UNIXWARE, and a few other folks do just that
with a linked list in the page structure. Anyhow its difficult to comment
without looking at linux implementation about merits and demerits of
maintaining all accessors to a page. Its sounds like quite a deviation
from the popular SVR4 design!

> Linux VM, but we don't need that functionality: in Linux we have always
> swapped out ptes on a per-page-table basis, not on a per-physical-page
> basis. We *DO* swap processes out independently.

I dont think I understand. The whole idea of doing it globally is to do
some kind of LRU on a global scale and swap out pages based on that.
Others unixes also swap processes out independently, but only in extreme
cases and even then if we can figure out all pte's refering to page, its
quite okay to invalidate them all and swap the page out.

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