|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <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 |
|
13 features of the File Server.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <section id="GUID-CBF527A2-EF30-5D4D-9BF4-631748315BE9"><title>Fair |
|
15 scheduling</title><p>The current design of the file server supports |
|
16 the processing of client requests concurrently, as long as those requests |
|
17 are made to different drives in the system. For example, a read operation |
|
18 may take place on the NAND user area partition while a write operation |
|
19 to the MMC card takes place concurrently. </p><p>However, requests |
|
20 to the same drive are serialized on a first-come first-served basis, |
|
21 which under some circumstances leads to bad user experience. For example:</p><ol> |
|
22 <li id="GUID-6550B420-5545-42C9-B304-9A8FA7D9DA01"><p>An incoming |
|
23 call arrives while a large video file is being written to the NAND |
|
24 user area by an application that writes the file in very large chunks.</p></li> |
|
25 <li id="GUID-7B08B626-E610-448B-917C-CB6CC127F2B9"><p>In order to |
|
26 display the caller’s details, the phone needs to read from the contacts |
|
27 database which is also stored on the NAND user area.</p></li> |
|
28 <li id="GUID-3A42569B-66CF-420F-A09D-F02A6BA4E4F9"><p>The write operation |
|
29 takes a very long time to complete, so the call is lost.</p></li> |
|
30 </ol><p> This is one of many scenarios where the single threaded nature |
|
31 of the file server may lead to unresponsive behavior. In order to |
|
32 improve the responsiveness of the system, the Symbian platform implements |
|
33 a fair scheduling policy that splits up large requests into more manageable |
|
34 chunks, thus providing clients of the file server with a more responsive |
|
35 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> |
|
36 <section id="GUID-84C18F69-D193-4010-A9B2-B533FC6ACF51"><title>Read |
|
37 caching</title><p>Read caching aims to improve file server performance |
|
38 by addressing the following use case: <ul> |
|
39 <li><p>A client (or multiple clients) issues repeated requests to |
|
40 read data from the same locality within a file. Data that was previously |
|
41 read (and is still in the cache) can be returned to the client without |
|
42 continuously re-reading the data from the media. </p></li> |
|
43 </ul></p><note>Read caching is of little benefit for clients/files |
|
44 that are typically accessed sequentially in large blocks and never |
|
45 re-read.</note><p>There may be a small degradation in performance |
|
46 on some media due to the overhead of copying the data from the media |
|
47 into the file cache. To some extent this may be mitigated by the affects |
|
48 of read-ahead, but this clearly does not affect large (>= 4K) reads |
|
49 and/or non-sequential reads. It should also be noted that any degradation |
|
50 may be more significant for media where the read is entirely synchronous, |
|
51 because there is no scope for a read-ahead to be running in the file |
|
52 server drive thread at the same time as reads are being satisfied |
|
53 in the context of the file server’s main thread.</p></section> |
|
54 <section id="GUID-7C6E6FDB-1419-4A8E-82F8-74EE6E62D468"><title>Demand |
|
55 paging effects</title><p>When ROM paging is enabled, the kernel maintains |
|
56 a <i>live list</i> of pages that are currently being used to store |
|
57 demand paged content. It is important to realize that this list also |
|
58 contains non-dirty pages belonging to the file cache. The implication |
|
59 of this is that reading some data into the file cache, or reading |
|
60 data already stored in the file cache, may result in code pages being |
|
61 evicted from the live list. </p><p>Having a large number of clients |
|
62 reading through or from the file cache can have an adverse effect |
|
63 on performance. For this reason it is probably not a good idea to |
|
64 set the <xref href="GUID-3B777E89-8E4C-3540-958F-C621741895C8.dita"><apiname>FileCacheSize</apiname></xref> property to too large a value |
|
65 – otherwise a single application reading a single large file through |
|
66 the cache is more likely to cause code page evictions if the amount |
|
67 of available RAM is restricted. See <xref href="GUID-EB2566BD-8F65-5A81-B215-E8B05CFE21C3.dita">Migration Tutorial: |
|
68 Demand Paging and Media Drivers</xref>.</p></section> |
|
69 <section id="GUID-9BCF8F2A-F919-4AC7-BA05-02CC763429C1"><title>Read-ahead |
|
70 caching</title><p>Clients that read data sequentially (particularly |
|
71 using small block lengths) impact system performance due to the overhead |
|
72 in requesting data from the media. Read-ahead caching addresses this |
|
73 issue by ensuring that subsequent small read operations may be satisfied |
|
74 from the cache after issuing a large request to read ahead data from |
|
75 the media.</p><p>Read-ahead caching builds on read caching by detecting |
|
76 clients that are performing streaming operations and speculatively |
|
77 reading ahead on the assumption that once the data is in the cache |
|
78 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 |
|
79 equal to double the client’s last read length or a page, for example, |
|
80 4K (whichever is greater) and doubles each time the file server detects |
|
81 that the client is due to read outside of the extents of the read-ahead |
|
82 cache, up to a pre-defined maximum (128K). </p></section> |
|
83 <section id="GUID-976EE014-E3C3-42FD-8467-1D008DEC27FD"><title>Write |
|
84 caching</title><p>Write caching is implemented to perform a small |
|
85 level of write-back caching. This overcomes inefficiencies of clients |
|
86 that perform small write operations, thus taking advantage of media |
|
87 that is written on a block basis by consolidating multiple file updates |
|
88 into a single larger write as well as minimizing the overhead of metadata |
|
89 updates that the file system performs. </p><p>By implementing write |
|
90 back at the file level, rather than at the level of the block device, |
|
91 the possibility of file system corruption is removed as the robustness |
|
92 features provided by rugged FAT and LFFS are still applicable.</p><p>Furthermore, by disabling write back by default, allowing the |
|
93 licensee to specify the policy on a per drive basis, providing APIs |
|
94 on a per session basis and respecting Flush and Close operations, |
|
95 the risk of data corruption is minimized.</p><note>The possibility |
|
96 of data loss increases, but the LFFS file system already implements |
|
97 a simple write back cache of 4K in size so the impact of this should |
|
98 be minimal.</note><note>Write caching must be handled with care, as |
|
99 this could potentially result in loss of user data.</note><p>Database |
|
100 access needs special consideration as corruption may occur if the |
|
101 database is written to expect write operations to be committed to |
|
102 disk immediately or in a certain order (write caching may re-order |
|
103 write requests).</p><p>For these reasons, it is probably safer to |
|
104 leave write caching off by default and to consider enabling it on |
|
105 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> |
|
106 </conbody></concept> |