Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!rice!rice!sun-spots-request
From: Mark_Weiser.PARC@xerox.com
Newsgroups: comp.sys.sun
Subject: Re: Sun 4 & MMU: further inquiry
Keywords: SunOS
Message-ID: <1990Oct31.235825.22792@rice.edu>
Date: 1 Nov 90 00:08:19 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 352, message 9
X-Original-Date: Wed, 10 Oct 1990 10:55:08 PDT
X-Refs:  Original: v9n351

"For programs dynamically linked (involving shared libraries), are pmegs
allocated for all potential members of the shared library?"

No, that is not the point.  Rather, the shared libraries cause the actual
addresses being mapped to be spread out all over, and every 256k of
address space with a page in use in it uses up a pmeg entry.  The actual
physcial pages in use are no larger, but the spread of addresses is.

"The point is made that shared text and data between processes still
involves non-shared pmegs (i.e., pmegs mapping the same pages aren't
shared).  Is this also true for multiple processes attaching to System V
shared memory segments?"

Yes.  PMEG entries are not shared across processes at all, even if they
are doing mmaps or shmops to specify sharing.  Furthermore, Sun's PMEG fix
patch does not repair this, but only makes swapping pmeg entries in and
out faster.

"It is implied that more than 16 megabytes of physical memory is typically
going to be used as a disk cache."

Implied by who where?  Anyway, it might be true.  The PMEG problem is not
a physical memory problem, but rather an addressing problem.  You can be
running completely in RAM and have 95% of your time going to the kernel
thrashing pmeg entries.  I've seen it.

-mark