<!-- HTML snippet loaded in the dashboard view -->
<center>Select a view from the menu above.</center>
<h1>Definitions</h1>
<dl>
    <dt>Silo</dt> <dd>A set of interchangeable slaves.  For example, a Darwin9
    slave isn't interchangeable with a Linux64 slave.  Silos are based on
    relatively fixed attributes of the slaves' hardware and sofware
    configuration -- attributes that cannot be changed without manual
    intervention.</dd>

    <dt>Pool</dt> <dd>a set of masters and slaves, where any of the slaves can
    be allocated to any of the masters.  Pools are the primary configuration
    knob for the allocator.</dd>

    <dt>Trustlevel<dt> <dd>The trust level specifies the kind of code that can
    run on this slave.  It currently maps to the various levels of
    version-control commit priviledges -- tryuser and core.</dd>
</dl>
<h1>Allocation Process</h1>
<p>Within each pool, the allocator attempts to balance the slaves in each silo across the available masters.  The balancing algorithm proceeds as follows:
<ul>
    <li> determine the pool for the slave</li>
    <li> determine the silo for the slave </li>
    <li> for each active master in the pool, count the number of attached slaves from the silo </li>
    <li> attach the new slave to the master with the lowest count, sorting by master name where counts are equal </li>
</ul>
</p>

<p>Note that the balancing applies to the intersection of a silo and a pool.
The more slaves in each such intersection, the better the allocator can
perform.  As such, we should make all efforts to minimize the number of
distinct pools and silos into which we divide our slaves.</p>