Changes between Version 6 and Version 7 of WikiStart


Ignore:
Timestamp:
Jul 27, 2005, 10:18:06 AM (14 years ago)
Author:
jtv
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v6 v7  
    102102
    103103
    104 == Technical details ==
    105 
    106 === Installation ===
    107 
    108 The installation procedure creates a directory ''/var/lib/swapspace'', which must be accessible to the system's superuser (root) __only__; granting any kind of access for this directory to an untrusted user is likely to constitute a serious security hole.
    109 
    110 According to the [http://www.pathname.com/fhs/ Filesystem Hierarchy Standard], other appropriate places for this kind of file might be ''/var/tmp'' or ''/var/run''.  The former was not deemed appropriate because it is accessible to all users, and the latter because most system administrators would probably expect it to occupy very little space and may confine it to a partition that isn't large enough to hold useful swap space.
    111 
    112 Also, files in ''/var/lib'' survive reboots whereas those in ''/var/tmp'' and ''/var/run'' need not.  Obviously any data in swap files can be safely erased on reboot (it's even tempting to think that that would be safer, though I don't think it really is).  But consider a system consistently short on physical memory: during boot, swapspace will see the swapfiles left by the previous session, and reinstate them immediately at very little cost, ready for use when they are needed.  If they had been erased during reboot, swapspace would have to allocate new ones on disk when it recognized the need for more virtual memory, which takes much more time and resources.
    113 
    114 === Algorithm ===
    115 
    116 Choices of allocation and deallocation are driven by a "finite state machine"
    117 consisting of four states: steady, hungry, overfed, and diet.  The program will
    118 alternate through these states as circumstances dictate, applying different
    119 policies depending on current state.  This was done to achieve a good tradeoff
    120 between willingness to free up unused swap space on the one hand, and avoidance
    121 of "thrashing" between deallocation and re-allocation of swapfiles on the other.
    122 
    123 For those interested, here is a quick description of these states and their
    124 associated policies:
    125 
    126 Steady - normal operation; no additional swap space is needed, nor do we have
    127 more than is needed.  However, the program can go into the hungry or overfed
    128 states at the drop of a hat.
    129 
    130 Hungry - more swap space was recently allocated.  The program is willing to
    131 allocate even more if needed, but it will not consider dropping unneeded swap
    132 files.  After a certain timeout period, the program reverts to the steady state.
    133 
    134 Overfed - significantly more virtual memory is available than is needed.  If
    135 this situation persists for a certain timeout period, a swapfile is deallocated
    136 and the program returns to the steady state.
    137 
    138 Diet - a recent allocation attempt has run into resource limits, e.g. because
    139 the filesystem used for swap files was full.  No more swapspace can be allocated
    140 but excess files can be freed up very rapidly.  Afer timeout, reverts to steady.
    141 
    142 State information can be queried by sending the program the SIGUSR1 signal (see
    143 "man 7 signal" to get the number for your architecture) which will cause it to
    144 log debug information to the system's daemon log and/or standard output, as
    145 appropriate.  The program can also be made to log state transitions by starting
    146 it with the ''-v'' or ''--verbose'' option.
    147 
     104See TechnicalDetails for more about how ''swapspace'' works.
    148105
    149106= This site runs on Trac 0.8.4 =