Adaptation/GUID-B35A70D2-1BC8-51DE-95BF-F315DB394582.dita
author Graeme Price <GRAEME.PRICE@NOKIA.COM>
Fri, 15 Oct 2010 14:32:18 +0100
changeset 15 307f4279f433
permissions -rw-r--r--
Initial contribution of the Adaptation Documentation.

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-B35A70D2-1BC8-51DE-95BF-F315DB394582" xml:lang="en"><title>Demand
Paging Overview</title><shortdesc>Demand paging is a technique where content appears to be present
in RAM, but may in fact be stored on some external media and is transparently
loaded when needed.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-733D5AEF-6488-5F11-ABA7-AB4E5B45F9D0"><title>Purpose</title> <p>Demand
paging trades off increased available RAM against increased data latency,
increased media wear and increased power usage. Overall performance may be
increased as there can be more RAM available to each application as it runs. </p> <p>Demand
paging is used to reduce the amount of RAM that needs to be shipped with a
device and so reduces the device cost. </p> </section>
<section id="GUID-BC958271-5F6B-59D4-A60D-21AB336377D9"><title>Description</title> <p>Demand
paging relies on the fact that most memory access is likely to occur in a
small region of memory and not spread over the entire memory map. This means
that if only that small area of memory is available to a process (or thread)
at any one time, then the amount of RAM required can be reduced. The small
area of memory is known as a page. The working RAM is broken down into pages,
some of which are used directly by the processor and the rest are spare. Since
Symbian platform is a multi-tasking operating system, there is more than one
page in the working RAM at any one time. There is one page per thread. </p> <p>There
are three types of demand paging: ROM paging, code paging and writable data
paging. All of these types of demand paging have some features in common: </p> <ul>
<li id="GUID-82F77F93-433B-59E8-B44E-0EC9F183B5C0"><p>A free RAM pool </p> </li>
<li id="GUID-7318C5DE-4342-51AB-8A2F-86F3B2DB6083"><p>Working RAM </p> </li>
<li id="GUID-296241B1-9896-5673-A9F3-E87F5404E66E"><p>Paging Fault Handler </p> </li>
<li id="GUID-D3C9BC6B-9F1F-56E9-9C31-ABFC172CD7D8"><p>A source of code and/or
data that the processor needs to access. </p> </li>
</ul> <p>With demand paging, the processor requires content to be present
in the working RAM. If the content is not present, then a 'paging fault' occurs
and the required information is loaded into a page of the working RAM. This
is known as "paged-in". When the contents of this page are no longer required,
then the page returns to the pool of free RAM. This is known as "paging-out". </p> <p>The
difference between the types of demand paging is the source that is to be
used: </p> <ul>
<li id="GUID-A6CAEFFD-729A-52C6-8576-15D069A287FB"><p>For ROM paging, it is
code and/or data stored under the <xref href="GUID-1B9EFA73-D949-5E8C-BD7C-17D37079FBC4.dita">ROM
file system</xref>  </p> </li>
<li id="GUID-BC64B7AB-2A33-573A-8F0B-C2EB10A49B51"><p>For code paging, it
is code and/or data stored using <xref href="GUID-02126A62-B2FA-5DAB-AC4D-536A3BCD7BA1.dita">ROFS
file system</xref>  </p> </li>
<li id="GUID-B511A99E-187F-5962-A0E8-2783B53834C7"><p>For writable data paging,
it is the writable data stored in RAM, for example user stacks and heaps.
In this case, the data is moved to a backing store. </p> </li>
</ul> <fig id="GUID-FDD6829A-DAF9-5752-9C3F-2338625054FA">
<image href="GUID-3FE9C184-1880-51E1-B045-3C2EA4BE204A_d0e78117_href.png" placement="inline"/>
</fig> <p>The diagram above shows the basic operations involved in demand
paging: </p> <ol id="GUID-598BA3E8-7BB9-585D-913B-5453D8500CBF">
<li id="GUID-E65CC155-049D-5351-9A01-5FCDA3263FAB"><p>The processor wants
to access content which is not available in the working RAM, causing a 'paging
fault'. </p> </li>
<li id="GUID-DF626329-9D08-5242-881A-15D8837BAA02"><p>The paging fault handler
starts the process for copying a page of the source into a page of RAM. </p> </li>
<li id="GUID-BB88798C-1D62-540B-A0C6-9C026E1D1DAB"><p>A page is selected. </p> </li>
<li id="GUID-CD8265F9-D42A-57B7-8A33-712FA4B9923F"><p>The contents of the
source is loaded into the page and this becomes part of the working memory. </p> </li>
<li id="GUID-721F338C-108F-58C9-B430-56730F26B66B"><p>When the contents of
the page are no longer required, the page is returned to the free RAM pool. </p> </li>
</ol> </section>
<section id="GUID-C2E6EE31-1AD6-4580-9296-E8E29E8C76F1"><title>Demand Paging features</title> <p>Demand Paging provides the
following features: </p> <ul>
<li id="GUID-75F892EA-D389-50D2-98AF-F66D16CF89E4"><p>Reduced amount of RAM
required </p> </li>
<li id="GUID-4356F1F0-1DB1-5DBE-AB30-B4AB4883144C"><p>Improved performance
in applications that involve loading a large amount of code into RAM, since
the number of memory access operations required has been reduced </p> </li>
<li id="GUID-21B9223E-2218-5AAA-8611-4DFAB63224BC"><p>Improved stability in
Out Of Memory (OOM) conditions. </p> </li>
</ul> </section>
<section id="GUID-21427657-A93E-465D-AD6E-F26ED83D2734"><title>Demand Paging limitations</title> <p>The following are known
limitations of Demand Paging: </p> <ul>
<li id="GUID-B41C667E-37DF-59B4-A115-E9232F0E293B"><p>The access time cannot
be guaranteed. </p> <p>There is an orders of magnitude difference in the access
time between an access where no page fault occurs and one where a page fault
occurs. If a page fault does not occur, then the time taken for a memory access
is in the tens to hundreds of nanosecond range. If a page fault does occur,
then the time taken for a memory access could be in the millisecond range </p> </li>
<li id="GUID-63D8300F-D884-530A-9394-A51183A399A5"><p>Device drivers have
to be written to allow for data latency when a page fault occurs. </p> </li>
</ul> </section>
</conbody><related-links>
<link href="GUID-6F82A35E-9F11-591D-AA5C-8F60734A2827.dita"><linktext>Demand Paging
Guides</linktext></link>
<link href="GUID-795B8649-B6C3-5540-B52A-9B460F35A5B5.dita"><linktext>ROM paging</linktext>
</link>
<link href="GUID-CE9EA167-0594-5E61-9640-6B2B63A92EA7.dita"><linktext>Code Paging</linktext>
</link>
<link href="GUID-2B7D04D9-98DE-5284-836D-01DB4FA8949D.dita"><linktext>Writable
Data Paging</linktext></link>
</related-links></concept>