--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-5B24741C-7CE0-58E8-98C9-1D1CACCD476F.dita Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,106 @@
+<?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-5B24741C-7CE0-58E8-98C9-1D1CACCD476F" xml:lang="en"><title>Fair Scheduling and File Caching Background</title><shortdesc>This document describes the fair scheduling and file caching
+features of the File Server.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-CBF527A2-EF30-5D4D-9BF4-631748315BE9"><title>Fair
+scheduling</title><p>The current design of the file server supports
+the processing of client requests concurrently, as long as those requests
+are made to different drives in the system. For example, a read operation
+may take place on the NAND user area partition while a write operation
+to the MMC card takes place concurrently. </p><p>However, requests
+to the same drive are serialized on a first-come first-served basis,
+which under some circumstances leads to bad user experience. For example:</p><ol>
+<li id="GUID-6550B420-5545-42C9-B304-9A8FA7D9DA01"><p>An incoming
+call arrives while a large video file is being written to the NAND
+user area by an application that writes the file in very large chunks.</p></li>
+<li id="GUID-7B08B626-E610-448B-917C-CB6CC127F2B9"><p>In order to
+display the caller’s details, the phone needs to read from the contacts
+database which is also stored on the NAND user area.</p></li>
+<li id="GUID-3A42569B-66CF-420F-A09D-F02A6BA4E4F9"><p>The write operation
+takes a very long time to complete, so the call is lost.</p></li>
+</ol><p> This is one of many scenarios where the single threaded nature
+of the file server may lead to unresponsive behavior. In order to
+improve the responsiveness of the system, the Symbian platform implements
+a fair scheduling policy that splits up large requests into more manageable
+chunks, thus providing clients of the file server with a more responsive
+system when the file server is under heavy load.</p><p>See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-450D57A3-928B-5389-B941-595DB20A7CEA">Enabling fair scheduling</xref>.</p></section>
+<section id="GUID-84C18F69-D193-4010-A9B2-B533FC6ACF51"><title>Read
+caching</title><p>Read caching aims to improve file server performance
+by addressing the following use case: <ul>
+<li><p>A client (or multiple clients) issues repeated requests to
+read data from the same locality within a file. Data that was previously
+read (and is still in the cache) can be returned to the client without
+continuously re-reading the data from the media. </p></li>
+</ul></p><note>Read caching is of little benefit for clients/files
+that are typically accessed sequentially in large blocks and never
+re-read.</note><p>There may be a small degradation in performance
+on some media due to the overhead of copying the data from the media
+into the file cache. To some extent this may be mitigated by the affects
+of read-ahead, but this clearly does not affect large (>= 4K) reads
+and/or non-sequential reads. It should also be noted that any degradation
+may be more significant for media where the read is entirely synchronous,
+because there is no scope for a read-ahead to be running in the file
+server drive thread at the same time as reads are being satisfied
+in the context of the file server’s main thread.</p></section>
+<section id="GUID-7C6E6FDB-1419-4A8E-82F8-74EE6E62D468"><title>Demand
+paging effects</title><p>When ROM paging is enabled, the kernel maintains
+a <i>live list</i> of pages that are currently being used to store
+demand paged content. It is important to realize that this list also
+contains non-dirty pages belonging to the file cache. The implication
+of this is that reading some data into the file cache, or reading
+data already stored in the file cache, may result in code pages being
+evicted from the live list. </p><p>Having a large number of clients
+reading through or from the file cache can have an adverse effect
+on performance. For this reason it is probably not a good idea to
+set the <xref href="GUID-3B777E89-8E4C-3540-958F-C621741895C8.dita"><apiname>FileCacheSize</apiname></xref> property to too large a value
+– otherwise a single application reading a single large file through
+the cache is more likely to cause code page evictions if the amount
+of available RAM is restricted. See <xref href="GUID-EB2566BD-8F65-5A81-B215-E8B05CFE21C3.dita">Migration Tutorial:
+Demand Paging and Media Drivers</xref>.</p></section>
+<section id="GUID-9BCF8F2A-F919-4AC7-BA05-02CC763429C1"><title>Read-ahead
+caching</title><p>Clients that read data sequentially (particularly
+using small block lengths) impact system performance due to the overhead
+in requesting data from the media. Read-ahead caching addresses this
+issue by ensuring that subsequent small read operations may be satisfied
+from the cache after issuing a large request to read ahead data from
+the media.</p><p>Read-ahead caching builds on read caching by detecting
+clients that are performing streaming operations and speculatively
+reading ahead on the assumption that once the data is in the cache
+it is likely to be accessed in the near future, thus improving performance.</p><p>The number of bytes requested by the read-ahead mechanism is initially
+equal to double the client’s last read length or a page, for example,
+4K (whichever is greater) and doubles each time the file server detects
+that the client is due to read outside of the extents of the read-ahead
+cache, up to a pre-defined maximum (128K). </p></section>
+<section id="GUID-976EE014-E3C3-42FD-8467-1D008DEC27FD"><title>Write
+caching</title><p>Write caching is implemented to perform a small
+level of write-back caching. This overcomes inefficiencies of clients
+that perform small write operations, thus taking advantage of media
+that is written on a block basis by consolidating multiple file updates
+into a single larger write as well as minimizing the overhead of metadata
+updates that the file system performs. </p><p>By implementing write
+back at the file level, rather than at the level of the block device,
+the possibility of file system corruption is removed as the robustness
+features provided by rugged FAT and LFFS are still applicable.</p><p>Furthermore, by disabling write back by default, allowing the
+licensee to specify the policy on a per drive basis, providing APIs
+on a per session basis and respecting Flush and Close operations,
+the risk of data corruption is minimized.</p><note>The possibility
+of data loss increases, but the LFFS file system already implements
+a simple write back cache of 4K in size so the impact of this should
+be minimal.</note><note>Write caching must be handled with care, as
+this could potentially result in loss of user data.</note><p>Database
+access needs special consideration as corruption may occur if the
+database is written to expect write operations to be committed to
+disk immediately or in a certain order (write caching may re-order
+write requests).</p><p>For these reasons, it is probably safer to
+leave write caching off by default and to consider enabling it on
+a per-application basis. See <xref href="GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30.dita#GUID-89BCF9A5-ABBD-5523-BA76-FDB00B806A30/GUID-719C7E0C-790B-5C61-9EA8-E2687397340F">Enabling read and write caching</xref>.</p></section>
+</conbody></concept>
\ No newline at end of file