Starting with the Solaris 2.6 release, the ability to use different page placement policies on the UltraSPARC® (sun4u) platform was introduced. A page placement policy attempts to allocate physical page addresses to maximize the use of the L2 cache. Whatever algorithm is chosen as the default algorithm, that algorithm can potentially provide less optimal results than another algorithm for a particular application set. This parameter changes the placement algorithm selected for all processes on the system.
Based on the size of the L2 cache, memory is divided into bins. The page placement code allocates a page from a bin when a page fault first occurs on an unmapped page. The page chosen depends on which of the three possible algorithms are used:
Page coloring – Various bits of the virtual address are used to determine the bin from which the page is selected. This is the default algorithm in the Solaris 8 release. consistent_coloring is set to zero to use this algorithm. No per-process history exists for this algorithm.
Virtual addr=physical address – Consecutive pages in the program selects pages from consecutive bins. consistent_coloring is set to 1 to use this algorithm. No per-process history exists for this algorithm.
Bin-hopping – Consecutive pages in the program generally allocate pages from every other bin, but the algorithm occasionally skips more bins. consistent_coloring is set to 2 to use this algorithm. Each process starts at a randomly selected bin, and a per-process memory of the last bin allocated is kept.
Yes
None. Values larger than 2 cause a number of WARNING: AS_2_BIN: bad consistent coloring value messages to appear on the console. The system hangs immediately thereafter. A power-cycle is required to recover.
When the primary workload of the system is a set of long-running high-performance computing (HPC) applications. Changing this value might provide better performance. File servers, database servers, and systems with a number of active processes (for example, compile or time sharing servers) do not benefit from changes.
Unstable
Initializes tsb_alloc_hiwater to impose an upper limit on the amount of physical memory that can be allocated for translation storage buffers (TSBs) as follows:
tsb_alloc_hiwater = physical memory (bytes) / tsb_alloc_hiwater_factor
When the memory that is allocated to TSBs is equal to the value of tsb_alloc_hiwater, the TSB memory allocation algorithm attempts to reclaim TSB memory as pages are unmapped.
Exercise caution when using this factor to increase the value of tsb_alloc_hiwater. To prevent system hangs, the resulting high water value must be considerably lower than the value of swapfs_minfree and segspt_minfree.
Integer
32
1 to MAXINIT
Note that a factor of 1 makes all physical memory available for allocation to TSBs, which could cause the system to hang. A factor that is too high will not leave memory available for allocation to TSBs, decreasing system performance.
Yes
None
Change the value of this parameter if the system has many processes that attach to very large shared memory segments. Under most circumstances, tuning of this variable is not necessary.
Unstable
Selects size of the initial translation storage buffers (TSBs) allocated to all processes.
Integer
Default is 0 (8 Kbytes), which corresponds to 512 entries
Possible values are:
Value |
Description |
---|---|
0 |
8 Kbytes |
1 |
16 Kbytes |
3 |
32 Kbytes |
4 |
128 Kbytes |
5 |
256 Kbytes |
6 |
512 Kbytes |
7 |
1 Mbyte |
Yes
None
Generally, you do not need to change this value. However, doing so might provide some advantages if the majority of processes on the system have a larger than average working set, or if resident set size (RSS) sizing is disabled.
Unstable
For information, see default_tsb_size (Solaris 10 Releases).
Enables a resident set size (RSS) based TSB sizing heuristic.
Boolean
1 (TSBs can be resized)
0 (TSBs remain at tsb_default_size) or 1 (TSBs can be resized)
If set to 0, then tsb_rss_factor is ignored.
Yes
Yes
Can be set to 0 to prevent growth of the TSBs. Under most circumstances, this parameter should be left at the default setting.
Unstable
For information, see enable_tsb_rss_sizing (Solaris 10 Releases).
Controls the RSS to TSB span ratio of the RSS sizing heuristic. This factor divided by 512 yields the percentage of the TSB span which must be resident in memory before the TSB is considered as a candidate for resizing.
Integer
384, resulting in a value of 75%. Thus, when the TSB is 3/4 full, its size will be increased. Note that some virtual addresses typically map to the same slot in the TSB. Therefore, conflicts can occur before the TSB is at 100% full.
0 to 512
Yes
None
If the system is experiencing an excessive number of traps due to TSB misses, for example, due to virtual address conflicts in the TSB, you might consider decreasing this value toward 0.
For example, changing tsb_rss_factor to 256 (effectively, 50%) instead of 384 (effectively, 75%) might help eliminate virtual address conflicts in the TSB in some cases, but will use more kernel memory, particularly on a heavily loaded system.
TSB activity can be monitored with the trapstat -T command.
Unstable
For information, see tsb_rss_factor (Solaris 10 Releases).