Changes between Version 6 and Version 7 of WikiStart

Jul 27, 2005, 10:18:06 AM (14 years ago)



  • WikiStart

    v6 v7  
    104 == Technical details ==
    106 === Installation ===
    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.
    110 According to the [ 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.
    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.
    114 === Algorithm ===
    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.
    123 For those interested, here is a quick description of these states and their
    124 associated policies:
    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.
    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.
    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.
    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.
    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.
     104See TechnicalDetails for more about how ''swapspace'' works.
    149106= This site runs on Trac 0.8.4 =