Here's my first pass at a VM requirements document,
for the embedded, desktop, and server cases. At the end is
a summary of general rules that should take care of all of
these cases.
Bandwidth Descriptions:
immediate: RAM, on-chip cache, etc.
fast: Flash reads, ROMs, etc.
medium: Hard drives, CD-ROMs, 100Mb ethernet, etc.
slow: Flash writes, floppy disks, CD-WR burners
packeted: Reads/write should be in as large a packet as possible
Embedded Case
-------------
Overview
--------
In the embedded case, the primary VM motiviation is to
use as _little_ caching of the filesystem for reads as
possible because (a) reads are very fast and (b) we don't
have any swap. However, we want to cache _writes_ as hard
as possible, because Flash is slow, and prone to wear.
Machine Description
------------------
RAM: 4-64Mb (reads: immediate, writes: immediate)
Flash: 4-128Mb (reads: fast, writes: slow, packeted)
CDROM: 640-800Mb (reads: medium)
Swap: 0Mb
Motiviations
------------
* Don't write to the (slow,packeted) devices until
you need to free up memory for processes.
* Never cache reads from immediate/fast devices.
Desktop Case
------------
Overview
--------
On the desktop, interactivity is king. We don't want to eat
lots of I/O bandwidth paging in and out, however we also want
to cache as much of the FS as possible, to speed compiles and
multiple operations over the same sets of files.
Balancing this is the notion of 'cache-hit-rates'. If our
access patterns aren't hitting cache, but disk instead, don't
swap out processes, just shrink the cache. Contrawise, if we
have good cache hit rates, swap out the idle tasks.
Machine Description
-------------------
RAM: 32Mb-1Gb (reads: immediate, writes: immediate)
HD: 1Gb-100Gb (reads: medium, writes: medium)
CDROM: 640-800Mb (reads: medium)
DVD: 1Gb-8Gb (reads: medium)
Swap: RAM size (HD speeds)
Motivations
-----------
* If we're getting low cache hit rates, don't flush
processes to swap.
* If we're getting good cache hit rates, flush old, idle
processes to swap.
Laptop Case
-----------
Overview
--------
Same as a desktop, except now you must treat the HDs as
packetized devices for power-saving.
Machine Description
-------------------
RAM: 32Mb-1Gb (reads: immediate, writes: immediate)
HD: 1Gb-100Gb (reads: medium,packeted, writes: medium,packeted)
CDROM: 640-800Mb (reads: medium)
DVD: 1Gb-8Gb (reads: medium)
Swap: RAM size (HD speeds)
Motivations
-----------
* Keep packetized devices as continuously-idle as possible.
Small chunks of idleness don't count. You want to have
maximal stetches of idleness for the device.
Server Case
-----------
Overview
--------
Same as a desktop, except that interactivity be damned. You
want processes to _rarely_ have to wait for swap-ins, and
you want as much read-ahead as possible. Idle tasks are pressed
firmly into cache to make room for running processes.
Machine Description
-------------------
RAM: 512Mb-64Gb (reads: immediate, writes: immediate)
HD: 10Gb-4Tb (reads: medium, writes: medium)
Swap: 2*RAM size (HD speeds)
Motivations
-----------
* Keep running processes as fully in memory as possible.
----------------------------- SUMMARY ----------------------------------
If we take all the motivations from the above, and list them,
we get:
* Don't write to the (slow,packeted) devices until
you need to free up memory for processes.
* Never cache reads from immediate/fast devices.
* If we're getting low cache hit rates, don't flush
processes to swap.
* If we're getting good cache hit rates, flush old, idle
processes to swap.
* Keep packetized devices as continuously-idle as possible.
Small chunks of idleness don't count. You want to have
maximal stetches of idleness for the device.
* Keep running processes as fully in memory as possible.
Oddly enough, they don't seem to conflict. I'll continue to
work on these motivations, and try to determine testable methods
of measuring the success of a VM versus these criteria.
Comments welcome.
-- Jason McMullan, Senior Linux Consultant Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Putting open source to work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:15 EST