--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-B35A70D2-1BC8-51DE-95BF-F315DB394582.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,99 @@
+<?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>
\ No newline at end of file