<?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</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 (for example, NAND on the H4 HRP), 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>