TIP: Click on subject to list as thread! ANSI
echo: nthelp
to: Gregg N
from: Rich
date: 2005-06-24 23:29:08
subject: Re: Page faults

From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01C57914.854781D0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   There is a different between soft faults and hard faults.  A soft =
fault is what a page is not in the working set of the process and while = a
page fault occurs the action to resolve the fault is to find the = already
loaded page in memory and to add it to the process working set.  = Soft
faults are relatively cheap.  Another form of fault you might be = seeing
are with demand zero pages.  This is a page you have allocated = but not
yet touched.  One first reference a physical page is allocated = and zero
filled.  Finally, one form of hard fault you could be taking is = with a
non-private page such as a page (code or data) from an executable = or a
mapped file page that is not modified so gets loaded from and = reloaded
from the executable or mapped file.  I haven't looked so this = may not
help but it may be that perfmon distinguishes between the = variations of
page fault and you can see which is which.

Rich

  "Gregg N"  wrote in message =
news:42bce597$1{at}w3.nls.net...

  Speaking of page files, we have a dedicated (semi-embedded) computer=20
  running Windows XP on which we have disabled paging in order to reduce =

  disk I/O (which has caused interrupt latency issues with our=20
  application). Since it is a dedicated application/computer with =
bounded=20
  memory usage, we either have enough RAM or we don't. There is no real=20
  need for a page file in this case.

  However, even though the page file size is zero, we have recently=20
  noticed that the application is constantly producing page faults (and =
a=20
  rather large number of them) at a rate similar to the processing rate =
of=20
  our application, even though the total committed memory is less than=20
  half the available physical memory. What would cause this, and do you=20
  know of a way to diagnose it?

  I understand that the operating system can page in from the image file =

  itself even if there is no page file, but why would it be constant =
after=20
  the initial set of faults if there is adequate memory?

  Thanks.

  Gregg
------=_NextPart_000_0069_01C57914.854781D0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   There is
a different =
between soft=20
faults and hard faults.  A soft fault is what a page is not in the
= working=20
set of the process and while a page fault occurs the action to resolve = the fault=20
is to find the already loaded page in memory and to add it to the = process=20
working set.  Soft faults are relatively cheap.  Another
form = of fault=20
you might be seeing are with demand zero pages.  This is a page
you = have=20
allocated but not yet touched.  One first reference a physical page = is=20
allocated and zero filled.  Finally, one form of hard fault you =
could be=20
taking is with a non-private page such as a page (code or data) from an=20
executable or a mapped file page that is not modified so gets loaded = from
and=20
reloaded from the executable or mapped file.  I haven't looked so
= this may=20
not help but it may be that perfmon distinguishes between the variations = of page=20
fault and you can see which is which.
 
Rich
 

  "Gregg N" <invalid{at}invalid.invalid>">mailto:invalid{at}invalid.invalid">invalid{at}invalid.invalid>
= wrote in=20
  message news:42bce597$1{at}w3.nls.net...Speaking=20
  of page files, we have a dedicated (semi-embedded) computer =
running=20
  Windows XP on which we have disabled paging in order to reduce =
disk I/O=20
  (which has caused interrupt latency issues with our application). =
Since it=20
  is a dedicated application/computer with bounded memory usage, we =
either=20
  have enough RAM or we don't. There is no real need for a page file =
in this=20
  case.However, even though the page file size is zero, we have =
recently=20
  noticed that the application is constantly producing page faults =
(and a=20
  rather large number of them) at a rate similar to the processing =
rate of=20
  our application, even though the total committed memory is less =
than=20
  half the available physical memory. What would cause this, and do =
you=20
  know of a way to diagnose it?I understand that the =
operating=20
  system can page in from the image file itself even if there is no =
page=20
  file, but why would it be constant after the initial set of faults =
if=20
  there is adequate =
memory?Thanks.Gregg

------=_NextPart_000_0069_01C57914.854781D0--

--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
SEEN-BY: 633/267 270 5030/786
@PATH: 379/45 1 106/2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.