<commit_before>---
authors: <NAME> <<EMAIL>>
contributors: <NAME> <<EMAIL>>
state: draft
---

# RFD 38 Zone Physical Memory Capping

## Summary

Various resource limits can be set on a zone to control how much of a specific
system resource the zone can consume. Almost all of these limits are defined in
terms of an rctl (see the resource_controls(5) man page) and set a hard cap on
the amount of the resource the zone can consume. However, the consumption of
physical memory falls into a separate category.

On a typical demand-paged virtual memory (VM) system, such as the one on
SmartOS, physical memory can be thought of as a page cache. Obviously the page
must be in physical memory to be used by the CPU, but each page has a backing
store, so pages can be freed and the physical page re-used for some other
backing object. The goal of the physical memory cap is to improve fairness
by trying to ensure that a single zone does not use more than its fair share
of the physical memory page cache at the expense of other zones.

There are a number of problems with the existing approach for physical memory
capping and we have pushed the current implementation about as far as possible.
The problems are described in this RFD, but to summarize, physcical memory
capping is hard to enforce, can induce unacceptable latency onto the
application, and is hard to accurately observe. A new approach is needed to
address the known problems.

## Current Behavior

The 'zoneadmd' associated with a zone is responsible for physical memory
capping. A thread will periodically run to determine the zone's overall
resident set size (RSS). When the thread determines that the zone is over its
cap, it will start iterating processes within the zone. It will grab each
process in turn and invalidate page mappings until the RSS has dropped below
the cap. If the RSS goes above the cap again at a later time, the thread picks
up where it left off and continues this activity.

## Issues

This section describes the current problems with physical memory capping in
more detail.

1. Accurate Accounting

   One of the primary issues is that there is no good way to determine how much
   physical memory a zone is consuming. This is because pages can be shared
   among multiple processes which map the backing object (e.g. each process
   which maps libc will back to the same file and share pages that come
   from libc). Furthermore, these pages can be shared across zones. Taking
   the libc example, a process in one zone might map in libc, then another<commit_msg>fix typo<commit_after>---
authors: <NAME> <<EMAIL>>
contributors: <NAME> <<EMAIL>>
state: draft
---

# RFD 38 Zone Physical Memory Capping

## Summary

Various resource limits can be set on a zone to control how much of a specific
system resource the zone can consume. Almost all of these limits are defined in
terms of an rctl (see the resource_controls(5) man page) and set a hard cap on
the amount of the resource the zone can consume. However, the consumption of
physical memory falls into a separate category.

On a typical demand-paged virtual memory (VM) system, such as the one on
SmartOS, physical memory can be thought of as a page cache. Obviously the page
must be in physical memory to be used by the CPU, but each page has a backing
store, so pages can be freed and the physical page re-used for some other
backing object. The goal of the physical memory cap is to improve fairness
by trying to ensure that a single zone does not use more than its fair share
of the physical memory page cache at the expense of other zones.

There are a number of problems with the existing approach for physical memory
capping and we have pushed the current implementation about as far as possible.
The problems are described in this RFD, but to summarize, physical memory
capping is hard to enforce, can induce unacceptable latency onto the
application, and is hard to accurately observe. A new approach is needed to
address the known problems.

## Current Behavior

The 'zoneadmd' associated with a zone is responsible for physical memory
capping. A thread will periodically run to determine the zone's overall
resident set size (RSS). When the thread determines that the zone is over its
cap, it will start iterating processes within the zone. It will grab each
process in turn and invalidate page mappings until the RSS has dropped below
the cap. If the RSS goes above the cap again at a later time, the thread picks
up where it left off and continues this activity.

## Issues

This section describes the current problems with physical memory capping in
more detail.

1. Accurate Accounting

   One of the primary issues is that there is no good way to determine how much
   physical memory a zone is consuming. This is because pages can be shared
   among multiple processes which map the backing object (e.g. each process
   which maps libc will back to the same file and share pages that come
   from libc). Furthermore, these pages can be shared across zones. Taking
   the libc example, a process in one zone might map in libc, then another
{'fraction_non_alphanumeric': 0.03176470588235294, 'fraction_numerical': 0.001568627450980392, 'mean_word_length': 4.152525252525253, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3665024', 'n_tokens_mistral': 1242, 'n_tokens_neox': 1182, 'n_words': 864}