diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml
index c3409a6717c..59eb35ad801 100644
--- a/xml/System/GCMemoryInfo.xml
+++ b/xml/System/GCMemoryInfo.xml
@@ -316,7 +316,12 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is
Gets the physical memory load when the last garbage collection occurred.
The physical memory load, in bytes, when the last garbage collection occurred.
- On Windows, memory load is a field in the MEMORYSTATUS structure. It's a number between 0 and 100 that specifies the approximate percentage of physical memory that's in use (0 indicates no memory use and 100 indicates full memory use). Corresponding information is given on other operating systems.
+ When a process is not running in a container or running in a container without a memory limit:
+ On Windows, the MemoryLoadBytes is obtained from the MEMORYSTATUS structure in bytes divided by the total physical memory.
+ On Linux, the MemoryLoadBytes is obtained from reading the MemAvailable field from `/proc/meminfo` divided by the total physical memory.
+ When a process is running in a container with a memory limit:
+ On Windows, the MemoryLoadBytes is obtained from the Working Set Size field in the PROCESS_MEMORY_COUNTERS structure in bytes divided by the memory limit.
+ On Linux, the MemoryLoadBytes is obtained from the used physical memory via the CGroup Memory Usage file from `/memory.usage_in_bytes` for CGroups v1 and `/memory.current` for CGroups v2 divided by the memory limit.
Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly.