🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13114

Re: paging performance

#13114
From: bobm
Date: Sat, 28 Feb 1987 03:13
49 lines
2921 bytes
In an article, rhg@forbrk writes:
>                                A high-end disk controller is also
> being designed part of whose purpose is to provide a  page  cache
> in  the  controller ram for pages which the os believes have been
> swapped to disk.

Be advised that the Berkeley virtual memory system already uses all
of free memory as a cache for pages that have been swapped.  Unless
memory on the controller is much cheaper than more main memory, don't
bother putting a cache on the controller; just add more main memory.
I wouldn't know if it's cheaper or not, because I'm just an OS flunky,
not a hardware type.

In gory detail, the way the Berkeley system works is this.
When a process gives up a page, the page's contents may or may not
be reclaimable in the future.  Examples of reclaimable pages are a page
that has been stolen from the process by the pageout daemon (the
process will probably eventually fault the page back) and a read-only
text (code) page (some other process may come along and execute the
same program and reference the same page).  An example of a page
that can't be reclaimed is a read/write data page belonging to an
exiting process.

There is a free page list, and it is structured so that non-reclaimable
pages are reused before reclaimable pages.  So the free list tends to
contain mostly pages that are reclaimable.

So if you cache things in disk-controller memory instead of in main
memory, you could let the free memory minimum get lower (especially
if the controller cached data to be written too), but you'd have to
pay for the DMA cycles to get things paged back in.  That means
possibly reduced processor speed while the DMA goes on as well
as longer latency when reclaiming pages from the cache.

Besides, how does the disk controller distinguish between paging
I/O and file I/O?  Or are you going to defeat the Unix buffer cache too?

"Computers are my forte."		K<bob>

deep_thought()				Bob Miller
{					Convex Computer Corporation
    sleep(years_to_seconds(7500000));	Richardson, Texas
    return 42;
}					{ihnp4,cbosgd,allegra,sun}!convex!bobm

Disclaimer: The above is not just the opinion of the author; it is the opinion
of all sentient beings in this universe and all other known universes.  The
author's employer may, however, not be sentient.
Technical Details
Message-ID: <116200001@convexs>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!convex!convexs!bobm
References: <196@forbrk.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!convex!convexs!bobm
From: bobm@convexs.UUCP
Newsgroups: comp.arch
Subject: Re: paging performance
Message-ID: <116200001@convexs>
Date: Fri, 27-Feb-87 22:13:00 EST
Article-I.D.: convexs.116200001
Posted: Fri Feb 27 22:13:00 1987
Date-Received: Mon, 2-Mar-87 03:49:25 EST
References: <196@forbrk.UUCP>
Lines: 49
Nf-ID: #R:forbrk.UUCP:196:convexs:116200001:000:2308
Nf-From: convexs.UUCP!bobm    Feb 27 21:13:00 1987