2019-08-12 22:30:39 +00:00
|
|
|
// Copyright 2019 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
// Page allocator.
|
|
|
|
|
//
|
|
|
|
|
// The page allocator manages mapped pages (defined by pageSize, NOT
|
|
|
|
|
// physPageSize) for allocation and re-use. It is embedded into mheap.
|
|
|
|
|
//
|
|
|
|
|
// Pages are managed using a bitmap that is sharded into chunks.
|
|
|
|
|
// In the bitmap, 1 means in-use, and 0 means free. The bitmap spans the
|
2019-11-14 23:58:50 +00:00
|
|
|
// process's address space. Chunks are managed in a sparse-array-style structure
|
|
|
|
|
// similar to mheap.arenas, since the bitmap may be large on some systems.
|
2019-08-12 22:30:39 +00:00
|
|
|
//
|
|
|
|
|
// The bitmap is efficiently searched by using a radix tree in combination
|
|
|
|
|
// with fast bit-wise intrinsics. Allocation is performed using an address-ordered
|
|
|
|
|
// first-fit approach.
|
|
|
|
|
//
|
|
|
|
|
// Each entry in the radix tree is a summary that describes three properties of
|
|
|
|
|
// a particular region of the address space: the number of contiguous free pages
|
|
|
|
|
// at the start and end of the region it represents, and the maximum number of
|
|
|
|
|
// contiguous free pages found anywhere in that region.
|
|
|
|
|
//
|
|
|
|
|
// Each level of the radix tree is stored as one contiguous array, which represents
|
|
|
|
|
// a different granularity of subdivision of the processes' address space. Thus, this
|
|
|
|
|
// radix tree is actually implicit in these large arrays, as opposed to having explicit
|
|
|
|
|
// dynamically-allocated pointer-based node structures. Naturally, these arrays may be
|
|
|
|
|
// quite large for system with large address spaces, so in these cases they are mapped
|
|
|
|
|
// into memory as needed. The leaf summaries of the tree correspond to a bitmap chunk.
|
|
|
|
|
//
|
|
|
|
|
// The root level (referred to as L0 and index 0 in pageAlloc.summary) has each
|
|
|
|
|
// summary represent the largest section of address space (16 GiB on 64-bit systems),
|
|
|
|
|
// with each subsequent level representing successively smaller subsections until we
|
|
|
|
|
// reach the finest granularity at the leaves, a chunk.
|
|
|
|
|
//
|
|
|
|
|
// More specifically, each summary in each level (except for leaf summaries)
|
|
|
|
|
// represents some number of entries in the following level. For example, each
|
|
|
|
|
// summary in the root level may represent a 16 GiB region of address space,
|
|
|
|
|
// and in the next level there could be 8 corresponding entries which represent 2
|
|
|
|
|
// GiB subsections of that 16 GiB region, each of which could correspond to 8
|
|
|
|
|
// entries in the next level which each represent 256 MiB regions, and so on.
|
|
|
|
|
//
|
|
|
|
|
// Thus, this design only scales to heaps so large, but can always be extended to
|
|
|
|
|
// larger heaps by simply adding levels to the radix tree, which mostly costs
|
|
|
|
|
// additional virtual address space. The choice of managing large arrays also means
|
|
|
|
|
// that a large amount of virtual address space may be reserved by the runtime.
|
|
|
|
|
|
|
|
|
|
package runtime
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
import (
|
2024-02-01 10:21:14 +08:00
|
|
|
"internal/runtime/atomic"
|
2025-03-04 19:02:48 +00:00
|
|
|
"internal/runtime/gc"
|
2019-08-14 16:32:12 +00:00
|
|
|
"unsafe"
|
|
|
|
|
)
|
|
|
|
|
|
2019-08-12 22:30:39 +00:00
|
|
|
const (
|
|
|
|
|
// The size of a bitmap chunk, i.e. the amount of bits (that is, pages) to consider
|
|
|
|
|
// in the bitmap at once.
|
|
|
|
|
pallocChunkPages = 1 << logPallocChunkPages
|
|
|
|
|
pallocChunkBytes = pallocChunkPages * pageSize
|
|
|
|
|
logPallocChunkPages = 9
|
2025-03-04 19:02:48 +00:00
|
|
|
logPallocChunkBytes = logPallocChunkPages + gc.PageShift
|
2019-08-12 22:30:39 +00:00
|
|
|
|
|
|
|
|
// The number of radix bits for each level.
|
|
|
|
|
//
|
|
|
|
|
// The value of 3 is chosen such that the block of summaries we need to scan at
|
|
|
|
|
// each level fits in 64 bytes (2^3 summaries * 8 bytes per summary), which is
|
|
|
|
|
// close to the L1 cache line width on many systems. Also, a value of 3 fits 4 tree
|
2019-08-14 16:32:12 +00:00
|
|
|
// levels perfectly into the 21-bit pallocBits summary field at the root level.
|
2019-08-12 22:30:39 +00:00
|
|
|
//
|
|
|
|
|
// The following equation explains how each of the constants relate:
|
|
|
|
|
// summaryL0Bits + (summaryLevels-1)*summaryLevelBits + logPallocChunkBytes = heapAddrBits
|
|
|
|
|
//
|
|
|
|
|
// summaryLevels is an architecture-dependent value defined in mpagealloc_*.go.
|
|
|
|
|
summaryLevelBits = 3
|
|
|
|
|
summaryL0Bits = heapAddrBits - logPallocChunkBytes - (summaryLevels-1)*summaryLevelBits
|
2019-08-14 16:32:12 +00:00
|
|
|
|
2019-11-14 23:58:50 +00:00
|
|
|
// pallocChunksL2Bits is the number of bits of the chunk index number
|
|
|
|
|
// covered by the second level of the chunks map.
|
|
|
|
|
//
|
|
|
|
|
// See (*pageAlloc).chunks for more details. Update the documentation
|
|
|
|
|
// there should this change.
|
|
|
|
|
pallocChunksL2Bits = heapAddrBits - logPallocChunkBytes - pallocChunksL1Bits
|
|
|
|
|
pallocChunksL1Shift = pallocChunksL2Bits
|
2025-02-01 14:19:04 +01:00
|
|
|
|
|
|
|
|
vmaNamePageAllocIndex = "page alloc index"
|
2019-08-12 22:30:39 +00:00
|
|
|
)
|
2019-09-25 15:55:29 +00:00
|
|
|
|
2022-03-28 09:30:41 -07:00
|
|
|
// maxSearchAddr returns the maximum searchAddr value, which indicates
|
|
|
|
|
// that the heap has no free space.
|
2020-04-28 21:30:57 +00:00
|
|
|
//
|
2022-03-28 09:30:41 -07:00
|
|
|
// This function exists just to make it clear that this is the maximum address
|
2020-04-28 21:30:57 +00:00
|
|
|
// for the page allocator's search space. See maxOffAddr for details.
|
2022-03-28 09:30:41 -07:00
|
|
|
//
|
|
|
|
|
// It's a function (rather than a variable) because it needs to be
|
|
|
|
|
// usable before package runtime's dynamic initialization is complete.
|
|
|
|
|
// See #51913 for details.
|
|
|
|
|
func maxSearchAddr() offAddr { return maxOffAddr }
|
2020-04-28 21:30:57 +00:00
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// Global chunk index.
|
|
|
|
|
//
|
|
|
|
|
// Represents an index into the leaf level of the radix tree.
|
|
|
|
|
// Similar to arenaIndex, except instead of arenas, it divides the address
|
|
|
|
|
// space into chunks.
|
|
|
|
|
type chunkIdx uint
|
|
|
|
|
|
|
|
|
|
// chunkIndex returns the global index of the palloc chunk containing the
|
|
|
|
|
// pointer p.
|
|
|
|
|
func chunkIndex(p uintptr) chunkIdx {
|
runtime: make maxOffAddr reflect the actual address space upper bound
Currently maxOffAddr is defined in terms of the whole 64-bit address
space, assuming that it's all supported, by using ^uintptr(0) as the
maximal address in the offset space. In reality, the maximal address in
the offset space is (1<<heapAddrBits)-1 because we don't have more than
that actually available to us on a given platform.
On most platforms this is fine, because arenaBaseOffset is just
connecting two segments of address space, but on AIX we use it as an
actual offset for the starting address of the available address space,
which is limited. This means using ^uintptr(0) as the maximal address in
the offset address space causes wrap-around, especially when we just
want to represent a range approximately like [addr, infinity), which
today we do by using maxOffAddr.
To fix this, we define maxOffAddr more appropriately, in terms of
(1<<heapAddrBits)-1.
This change also redefines arenaBaseOffset to not be the negation of the
virtual address corresponding to address zero in the virtual address
space, but instead directly as the virtual address corresponding to
zero. This matches the existing documentation more closely and makes the
logic around arenaBaseOffset decidedly simpler, especially when trying
to reason about its use on AIX.
Fixes #38966.
Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611
Reviewed-on: https://go-review.googlesource.com/c/go/+/233497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-05-12 16:08:50 +00:00
|
|
|
return chunkIdx((p - arenaBaseOffset) / pallocChunkBytes)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2022-10-03 01:32:11 +00:00
|
|
|
// chunkBase returns the base address of the palloc chunk at index ci.
|
2019-08-14 16:32:12 +00:00
|
|
|
func chunkBase(ci chunkIdx) uintptr {
|
runtime: make maxOffAddr reflect the actual address space upper bound
Currently maxOffAddr is defined in terms of the whole 64-bit address
space, assuming that it's all supported, by using ^uintptr(0) as the
maximal address in the offset space. In reality, the maximal address in
the offset space is (1<<heapAddrBits)-1 because we don't have more than
that actually available to us on a given platform.
On most platforms this is fine, because arenaBaseOffset is just
connecting two segments of address space, but on AIX we use it as an
actual offset for the starting address of the available address space,
which is limited. This means using ^uintptr(0) as the maximal address in
the offset address space causes wrap-around, especially when we just
want to represent a range approximately like [addr, infinity), which
today we do by using maxOffAddr.
To fix this, we define maxOffAddr more appropriately, in terms of
(1<<heapAddrBits)-1.
This change also redefines arenaBaseOffset to not be the negation of the
virtual address corresponding to address zero in the virtual address
space, but instead directly as the virtual address corresponding to
zero. This matches the existing documentation more closely and makes the
logic around arenaBaseOffset decidedly simpler, especially when trying
to reason about its use on AIX.
Fixes #38966.
Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611
Reviewed-on: https://go-review.googlesource.com/c/go/+/233497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-05-12 16:08:50 +00:00
|
|
|
return uintptr(ci)*pallocChunkBytes + arenaBaseOffset
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// chunkPageIndex computes the index of the page that contains p,
|
|
|
|
|
// relative to the chunk which contains p.
|
|
|
|
|
func chunkPageIndex(p uintptr) uint {
|
|
|
|
|
return uint(p % pallocChunkBytes / pageSize)
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-14 23:58:50 +00:00
|
|
|
// l1 returns the index into the first level of (*pageAlloc).chunks.
|
|
|
|
|
func (i chunkIdx) l1() uint {
|
|
|
|
|
if pallocChunksL1Bits == 0 {
|
|
|
|
|
// Let the compiler optimize this away if there's no
|
|
|
|
|
// L1 map.
|
|
|
|
|
return 0
|
|
|
|
|
} else {
|
|
|
|
|
return uint(i) >> pallocChunksL1Shift
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// l2 returns the index into the second level of (*pageAlloc).chunks.
|
|
|
|
|
func (i chunkIdx) l2() uint {
|
|
|
|
|
if pallocChunksL1Bits == 0 {
|
|
|
|
|
return uint(i)
|
|
|
|
|
} else {
|
|
|
|
|
return uint(i) & (1<<pallocChunksL2Bits - 1)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-28 21:30:57 +00:00
|
|
|
// offAddrToLevelIndex converts an address in the offset address space
|
|
|
|
|
// to the index into summary[level] containing addr.
|
|
|
|
|
func offAddrToLevelIndex(level int, addr offAddr) int {
|
runtime: make maxOffAddr reflect the actual address space upper bound
Currently maxOffAddr is defined in terms of the whole 64-bit address
space, assuming that it's all supported, by using ^uintptr(0) as the
maximal address in the offset space. In reality, the maximal address in
the offset space is (1<<heapAddrBits)-1 because we don't have more than
that actually available to us on a given platform.
On most platforms this is fine, because arenaBaseOffset is just
connecting two segments of address space, but on AIX we use it as an
actual offset for the starting address of the available address space,
which is limited. This means using ^uintptr(0) as the maximal address in
the offset address space causes wrap-around, especially when we just
want to represent a range approximately like [addr, infinity), which
today we do by using maxOffAddr.
To fix this, we define maxOffAddr more appropriately, in terms of
(1<<heapAddrBits)-1.
This change also redefines arenaBaseOffset to not be the negation of the
virtual address corresponding to address zero in the virtual address
space, but instead directly as the virtual address corresponding to
zero. This matches the existing documentation more closely and makes the
logic around arenaBaseOffset decidedly simpler, especially when trying
to reason about its use on AIX.
Fixes #38966.
Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611
Reviewed-on: https://go-review.googlesource.com/c/go/+/233497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-05-12 16:08:50 +00:00
|
|
|
return int((addr.a - arenaBaseOffset) >> levelShift[level])
|
2020-04-28 21:30:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// levelIndexToOffAddr converts an index into summary[level] into
|
|
|
|
|
// the corresponding address in the offset address space.
|
|
|
|
|
func levelIndexToOffAddr(level, idx int) offAddr {
|
runtime: make maxOffAddr reflect the actual address space upper bound
Currently maxOffAddr is defined in terms of the whole 64-bit address
space, assuming that it's all supported, by using ^uintptr(0) as the
maximal address in the offset space. In reality, the maximal address in
the offset space is (1<<heapAddrBits)-1 because we don't have more than
that actually available to us on a given platform.
On most platforms this is fine, because arenaBaseOffset is just
connecting two segments of address space, but on AIX we use it as an
actual offset for the starting address of the available address space,
which is limited. This means using ^uintptr(0) as the maximal address in
the offset address space causes wrap-around, especially when we just
want to represent a range approximately like [addr, infinity), which
today we do by using maxOffAddr.
To fix this, we define maxOffAddr more appropriately, in terms of
(1<<heapAddrBits)-1.
This change also redefines arenaBaseOffset to not be the negation of the
virtual address corresponding to address zero in the virtual address
space, but instead directly as the virtual address corresponding to
zero. This matches the existing documentation more closely and makes the
logic around arenaBaseOffset decidedly simpler, especially when trying
to reason about its use on AIX.
Fixes #38966.
Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611
Reviewed-on: https://go-review.googlesource.com/c/go/+/233497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-05-12 16:08:50 +00:00
|
|
|
return offAddr{(uintptr(idx) << levelShift[level]) + arenaBaseOffset}
|
2020-04-28 21:30:57 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// addrsToSummaryRange converts base and limit pointers into a range
|
|
|
|
|
// of entries for the given summary level.
|
|
|
|
|
//
|
|
|
|
|
// The returned range is inclusive on the lower bound and exclusive on
|
|
|
|
|
// the upper bound.
|
|
|
|
|
func addrsToSummaryRange(level int, base, limit uintptr) (lo int, hi int) {
|
|
|
|
|
// This is slightly more nuanced than just a shift for the exclusive
|
|
|
|
|
// upper-bound. Note that the exclusive upper bound may be within a
|
|
|
|
|
// summary at this level, meaning if we just do the obvious computation
|
|
|
|
|
// hi will end up being an inclusive upper bound. Unfortunately, just
|
2021-08-08 19:44:30 +09:30
|
|
|
// adding 1 to that is too broad since we might be on the very edge
|
2019-08-14 16:32:12 +00:00
|
|
|
// of a summary's max page count boundary for this level
|
|
|
|
|
// (1 << levelLogPages[level]). So, make limit an inclusive upper bound
|
|
|
|
|
// then shift, then add 1, so we get an exclusive upper bound at the end.
|
runtime: make maxOffAddr reflect the actual address space upper bound
Currently maxOffAddr is defined in terms of the whole 64-bit address
space, assuming that it's all supported, by using ^uintptr(0) as the
maximal address in the offset space. In reality, the maximal address in
the offset space is (1<<heapAddrBits)-1 because we don't have more than
that actually available to us on a given platform.
On most platforms this is fine, because arenaBaseOffset is just
connecting two segments of address space, but on AIX we use it as an
actual offset for the starting address of the available address space,
which is limited. This means using ^uintptr(0) as the maximal address in
the offset address space causes wrap-around, especially when we just
want to represent a range approximately like [addr, infinity), which
today we do by using maxOffAddr.
To fix this, we define maxOffAddr more appropriately, in terms of
(1<<heapAddrBits)-1.
This change also redefines arenaBaseOffset to not be the negation of the
virtual address corresponding to address zero in the virtual address
space, but instead directly as the virtual address corresponding to
zero. This matches the existing documentation more closely and makes the
logic around arenaBaseOffset decidedly simpler, especially when trying
to reason about its use on AIX.
Fixes #38966.
Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611
Reviewed-on: https://go-review.googlesource.com/c/go/+/233497
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-05-12 16:08:50 +00:00
|
|
|
lo = int((base - arenaBaseOffset) >> levelShift[level])
|
|
|
|
|
hi = int(((limit-1)-arenaBaseOffset)>>levelShift[level]) + 1
|
2019-08-14 16:32:12 +00:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// blockAlignSummaryRange aligns indices into the given level to that
|
|
|
|
|
// level's block width (1 << levelBits[level]). It assumes lo is inclusive
|
|
|
|
|
// and hi is exclusive, and so aligns them down and up respectively.
|
|
|
|
|
func blockAlignSummaryRange(level int, lo, hi int) (int, int) {
|
|
|
|
|
e := uintptr(1) << levelBits[level]
|
|
|
|
|
return int(alignDown(uintptr(lo), e)), int(alignUp(uintptr(hi), e))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type pageAlloc struct {
|
|
|
|
|
// Radix tree of summaries.
|
|
|
|
|
//
|
|
|
|
|
// Each slice's cap represents the whole memory reservation.
|
|
|
|
|
// Each slice's len reflects the allocator's maximum known
|
|
|
|
|
// mapped heap address for that level.
|
|
|
|
|
//
|
|
|
|
|
// The backing store of each summary level is reserved in init
|
|
|
|
|
// and may or may not be committed in grow (small address spaces
|
|
|
|
|
// may commit all the memory in init).
|
|
|
|
|
//
|
|
|
|
|
// The purpose of keeping len <= cap is to enforce bounds checks
|
|
|
|
|
// on the top end of the slice so that instead of an unknown
|
|
|
|
|
// runtime segmentation fault, we get a much friendlier out-of-bounds
|
|
|
|
|
// error.
|
|
|
|
|
//
|
2019-11-18 19:23:39 +00:00
|
|
|
// To iterate over a summary level, use inUse to determine which ranges
|
|
|
|
|
// are currently available. Otherwise one might try to access
|
|
|
|
|
// memory which is only Reserved which may result in a hard fault.
|
|
|
|
|
//
|
2019-08-14 16:32:12 +00:00
|
|
|
// We may still get segmentation faults < len since some of that
|
|
|
|
|
// memory may not be committed yet.
|
|
|
|
|
summary [summaryLevels][]pallocSum
|
|
|
|
|
|
|
|
|
|
// chunks is a slice of bitmap chunks.
|
|
|
|
|
//
|
2019-11-14 23:58:50 +00:00
|
|
|
// The total size of chunks is quite large on most 64-bit platforms
|
|
|
|
|
// (O(GiB) or more) if flattened, so rather than making one large mapping
|
|
|
|
|
// (which has problems on some platforms, even when PROT_NONE) we use a
|
|
|
|
|
// two-level sparse array approach similar to the arena index in mheap.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
|
|
|
|
// To find the chunk containing a memory address `a`, do:
|
2019-11-14 23:58:50 +00:00
|
|
|
// chunkOf(chunkIndex(a))
|
|
|
|
|
//
|
|
|
|
|
// Below is a table describing the configuration for chunks for various
|
|
|
|
|
// heapAddrBits supported by the runtime.
|
|
|
|
|
//
|
|
|
|
|
// heapAddrBits | L1 Bits | L2 Bits | L2 Entry Size
|
|
|
|
|
// ------------------------------------------------
|
|
|
|
|
// 32 | 0 | 10 | 128 KiB
|
|
|
|
|
// 33 (iOS) | 0 | 11 | 256 KiB
|
|
|
|
|
// 48 | 13 | 13 | 1 MiB
|
|
|
|
|
//
|
|
|
|
|
// There's no reason to use the L1 part of chunks on 32-bit, the
|
|
|
|
|
// address space is small so the L2 is small. For platforms with a
|
|
|
|
|
// 48-bit address space, we pick the L1 such that the L2 is 1 MiB
|
|
|
|
|
// in size, which is a good balance between low granularity without
|
|
|
|
|
// making the impact on BSS too high (note the L1 is stored directly
|
|
|
|
|
// in pageAlloc).
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2019-11-18 19:23:39 +00:00
|
|
|
// To iterate over the bitmap, use inUse to determine which ranges
|
|
|
|
|
// are currently available. Otherwise one might iterate over unused
|
|
|
|
|
// ranges.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
runtime: don't hold the heap lock while scavenging
This change modifies the scavenger to no longer hold the heap lock while
actively scavenging pages. To achieve this, the change also:
* Reverses the locking behavior of the (*pageAlloc).scavenge API, to
only acquire the heap lock when necessary.
* Introduces a new lock on the scavenger-related fields in a pageAlloc
so that access to those fields doesn't require the heap lock. There
are a few places in the scavenge path, notably reservation, that
requires synchronization. The heap lock is far too heavy handed for
this case.
* Changes the scavenger to marks pages that are actively being scavenged
as allocated, and "frees" them back to the page allocator the usual
way.
* Lifts the heap-growth scavenging code out of mheap.grow, where the
heap lock is held, and into allocSpan, just after the lock is
released. Releasing the lock during mheap.grow is not feasible if we
want to ensure that allocation always makes progress (post-growth,
another allocator could come in and take all that space, forcing the
goroutine that just grew the heap to do so again).
This change means that the scavenger now must do more work for each
scavenge, but it is also now much more scalable. Although in theory it's
not great by always taking the locked paths in the page allocator, it
takes advantage of some properties of the allocator:
* Most of the time, the scavenger will be working with one page at a
time. The page allocator's locked path is optimized for this case.
* On the allocation path, it doesn't need to do the find operation at
all; it can go straight to setting bits for the range and updating the
summary structure.
Change-Id: Ie941d5e7c05dcc96476795c63fef74bcafc2a0f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/353974
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2021-10-04 20:36:49 +00:00
|
|
|
// Protected by mheapLock.
|
|
|
|
|
//
|
2019-08-14 16:32:12 +00:00
|
|
|
// TODO(mknyszek): Consider changing the definition of the bitmap
|
|
|
|
|
// such that 1 means free and 0 means in-use so that summaries and
|
|
|
|
|
// the bitmaps align better on zero-values.
|
2019-11-14 23:58:50 +00:00
|
|
|
chunks [1 << pallocChunksL1Bits]*[1 << pallocChunksL2Bits]pallocData
|
2019-08-14 16:32:12 +00:00
|
|
|
|
2020-01-28 19:59:19 +00:00
|
|
|
// The address to start an allocation search with. It must never
|
|
|
|
|
// point to any memory that is not contained in inUse, i.e.
|
2020-07-13 19:51:50 +00:00
|
|
|
// inUse.contains(searchAddr.addr()) must always be true. The one
|
|
|
|
|
// exception to this rule is that it may take on the value of
|
|
|
|
|
// maxOffAddr to indicate that the heap is exhausted.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2020-07-13 19:51:50 +00:00
|
|
|
// We guarantee that all valid heap addresses below this value
|
|
|
|
|
// are allocated and not worth searching.
|
2020-04-28 21:30:57 +00:00
|
|
|
searchAddr offAddr
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// start and end represent the chunk indices
|
|
|
|
|
// which pageAlloc knows about. It assumes
|
|
|
|
|
// chunks in the range [start, end) are
|
|
|
|
|
// currently ready to use.
|
|
|
|
|
start, end chunkIdx
|
|
|
|
|
|
2019-11-15 23:30:30 +00:00
|
|
|
// inUse is a slice of ranges of address space which are
|
|
|
|
|
// known by the page allocator to be currently in-use (passed
|
|
|
|
|
// to grow).
|
|
|
|
|
//
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
// We care much more about having a contiguous heap in these cases
|
|
|
|
|
// and take additional measures to ensure that, so in nearly all
|
|
|
|
|
// cases this should have just 1 element.
|
2019-11-15 23:30:30 +00:00
|
|
|
//
|
|
|
|
|
// All access is protected by the mheapLock.
|
|
|
|
|
inUse addrRanges
|
|
|
|
|
|
2019-11-21 17:05:14 +00:00
|
|
|
// scav stores the scavenger state.
|
|
|
|
|
scav struct {
|
runtime: redesign scavenging algorithm
Currently the runtime's scavenging algorithm involves running from the
top of the heap address space to the bottom (or as far as it gets) once
per GC cycle. Once it treads some ground, it doesn't tread it again
until the next GC cycle.
This works just fine for the background scavenger, for heap-growth
scavenging, and for debug.FreeOSMemory. However, it breaks down in the
face of a memory limit for small heaps in the tens of MiB. Basically,
because the scavenger never retreads old ground, it's completely
oblivious to new memory it could scavenge, and that it really *should*
in the face of a memory limit.
Also, every time some thread goes to scavenge in the runtime, it
reserves what could be a considerable amount of address space, hiding it
from other scavengers.
This change modifies and simplifies the implementation overall. It's
less code with complexities that are much better encapsulated. The
current implementation iterates optimistically over the address space
looking for memory to scavenge, keeping track of what it last saw. The
new implementation does the same, but instead of directly iterating over
pages, it iterates over chunks. It maintains an index of chunks (as a
bitmap over the address space) that indicate which chunks may contain
scavenge work. The page allocator populates this index, while scavengers
consume it and iterate over it optimistically.
This has a two key benefits:
1. Scavenging is much simpler: find a candidate chunk, and check it,
essentially just using the scavengeOne fast path. There's no need for
the complexity of iterating beyond one chunk, because the index is
lock-free and already maintains that information.
2. If pages are freed to the page allocator (always guaranteed to be
unscavenged), the page allocator immediately notifies all scavengers
of the new source of work, avoiding the hiding issues of the old
implementation.
One downside of the new implementation, however, is that it's
potentially more expensive to find pages to scavenge. In the past, if
a single page would become free high up in the address space, the
runtime's scavengers would ignore it. Now that scavengers won't, one or
more scavengers may need to iterate potentially across the whole heap to
find the next source of work. For the background scavenger, this just
means a potentially less reactive scavenger -- overall it should still
use the same amount of CPU. It means worse overheads for memory limit
scavenging, but that's not exactly something with a baseline yet.
In practice, this shouldn't be too bad, hopefully since the chunk index
is extremely compact. For a 48-bit address space, the index is only 8
MiB in size at worst, but even just one physical page in the index is
able to support up to 128 GiB heaps, provided they aren't terribly
sparse. On 32-bit platforms, the index is only 128 bytes in size.
For #48409.
Change-Id: I72b7e74365046b18c64a6417224c5d85511194fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/399474
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-10 20:34:17 +00:00
|
|
|
// index is an efficient index of chunks that have pages available to
|
|
|
|
|
// scavenge.
|
|
|
|
|
index scavengeIndex
|
2019-11-21 17:05:14 +00:00
|
|
|
|
2023-05-17 16:36:07 +00:00
|
|
|
// releasedBg is the amount of memory released in the background this
|
|
|
|
|
// scavenge cycle.
|
|
|
|
|
releasedBg atomic.Uintptr
|
|
|
|
|
|
|
|
|
|
// releasedEager is the amount of memory released eagerly this scavenge
|
|
|
|
|
// cycle.
|
|
|
|
|
releasedEager atomic.Uintptr
|
2019-11-21 17:05:14 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// mheap_.lock. This level of indirection makes it possible
|
2023-02-07 09:09:24 +00:00
|
|
|
// to test pageAlloc independently of the runtime allocator.
|
2019-08-14 16:32:12 +00:00
|
|
|
mheapLock *mutex
|
|
|
|
|
|
|
|
|
|
// sysStat is the runtime memstat to update when new system
|
|
|
|
|
// memory is committed by the pageAlloc for allocation metadata.
|
2020-07-29 20:25:05 +00:00
|
|
|
sysStat *sysMemStat
|
2019-08-21 00:24:25 +00:00
|
|
|
|
runtime: track how much memory is mapped in the Ready state
This change adds a field to memstats called mappedReady that tracks how
much memory is in the Ready state at any given time. In essence, it's
the total memory usage by the Go runtime (with one exception which is
documented). Essentially, all memory mapped read/write that has either
been paged in or will soon.
To make tracking this not involve the many different stats that track
mapped memory, we track this statistic at a very low level. The downside
of tracking this statistic at such a low level is that it managed to
catch lots of situations where the runtime wasn't fully accounting for
memory. This change rectifies these situations by always accounting for
memory that's mapped in some way (i.e. always passing a sysMemStat to a
mem.go function), with *two* exceptions.
Rectifying these situations means also having the memory mapped during
testing being accounted for, so that tests (i.e. ReadMemStats) that
ultimately check mappedReady continue to work correctly without special
exceptions. We choose to simply account for this memory in other_sys.
Let's talk about the exceptions. The first is the arenas array for
finding heap arena metadata from an address is mapped as read/write in
one large chunk. It's tens of MiB in size. On systems with demand
paging, we assume that the whole thing isn't paged in at once (after
all, it maps to the whole address space, and it's exceedingly difficult
with today's technology to even broach having as much physical memory as
the total address space). On systems where we have to commit memory
manually, we use a two-level structure.
Now, the reason why this is an exception is because we have no mechanism
to track what memory is paged in, and we can't just account for the
entire thing, because that would *look* like an enormous overhead.
Furthermore, this structure is on a few really, really critical paths in
the runtime, so doing more explicit tracking isn't really an option. So,
we explicitly don't and call sysAllocOS to map this memory.
The second exception is that we call sysFree with no accounting to clean
up address space reservations, or otherwise to throw out mappings we
don't care about. In this case, also drop down to a lower level and call
sysFreeOS to explicitly avoid accounting.
The third exception is debuglog allocations. That is purely a debugging
facility and ideally we want it to have as small an impact on the
runtime as possible. If we include it in mappedReady calculations, it
could cause GC pacing shifts in future CLs, especailly if one increases
the debuglog buffer sizes as a one-off.
As of this CL, these are the only three places in the runtime that would
pass nil for a stat to any of the functions in mem.go. As a result, this
CL makes sysMemStats mandatory to facilitate better accounting in the
future. It's now much easier to grep and find out where accounting is
explicitly elided, because one doesn't have to follow the trail of
sysMemStat nil pointer values, and can just look at the function name.
For #48409.
Change-Id: I274eb467fc2603881717482214fddc47c9eaf218
Reviewed-on: https://go-review.googlesource.com/c/go/+/393402
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
2022-03-15 02:48:18 +00:00
|
|
|
// summaryMappedReady is the number of bytes mapped in the Ready state
|
|
|
|
|
// in the summary structure. Used only for testing currently.
|
|
|
|
|
//
|
|
|
|
|
// Protected by mheapLock.
|
|
|
|
|
summaryMappedReady uintptr
|
|
|
|
|
|
2023-01-03 17:59:48 +00:00
|
|
|
// chunkHugePages indicates whether page bitmap chunks should be backed
|
|
|
|
|
// by huge pages.
|
|
|
|
|
chunkHugePages bool
|
|
|
|
|
|
2019-08-21 00:24:25 +00:00
|
|
|
// Whether or not this struct is being used in tests.
|
|
|
|
|
test bool
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
func (p *pageAlloc) init(mheapLock *mutex, sysStat *sysMemStat, test bool) {
|
2019-08-14 16:32:12 +00:00
|
|
|
if levelLogPages[0] > logMaxPackedValue {
|
|
|
|
|
// We can't represent 1<<levelLogPages[0] pages, the maximum number
|
|
|
|
|
// of pages we need to represent at the root level, in a summary, which
|
|
|
|
|
// is a big problem. Throw.
|
|
|
|
|
print("runtime: root level max pages = ", 1<<levelLogPages[0], "\n")
|
|
|
|
|
print("runtime: summary max pages = ", maxPackedValue, "\n")
|
|
|
|
|
throw("root level max pages doesn't fit in summary")
|
|
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.sysStat = sysStat
|
2019-08-14 16:32:12 +00:00
|
|
|
|
2020-08-25 12:34:02 -04:00
|
|
|
// Initialize p.inUse.
|
|
|
|
|
p.inUse.init(sysStat)
|
2019-11-15 23:30:30 +00:00
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// System-dependent initialization.
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.sysInit(test)
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Start with the searchAddr in a state indicating there's no free memory.
|
2022-03-28 09:30:41 -07:00
|
|
|
p.searchAddr = maxSearchAddr()
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Set the mheapLock.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.mheapLock = mheapLock
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
|
2023-04-19 22:00:23 +00:00
|
|
|
// Initialize the scavenge index.
|
2023-04-20 02:41:08 +00:00
|
|
|
p.summaryMappedReady += p.scav.index.init(test, sysStat)
|
2023-04-19 22:00:23 +00:00
|
|
|
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
// Set if we're in a test.
|
|
|
|
|
p.test = test
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2020-09-09 16:52:18 +00:00
|
|
|
// tryChunkOf returns the bitmap data for the given chunk.
|
|
|
|
|
//
|
|
|
|
|
// Returns nil if the chunk data has not been mapped.
|
2020-08-25 12:34:02 -04:00
|
|
|
func (p *pageAlloc) tryChunkOf(ci chunkIdx) *pallocData {
|
|
|
|
|
l2 := p.chunks[ci.l1()]
|
2020-09-09 16:52:18 +00:00
|
|
|
if l2 == nil {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
return &l2[ci.l2()]
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-14 23:58:50 +00:00
|
|
|
// chunkOf returns the chunk at the given chunk index.
|
2020-09-09 16:52:18 +00:00
|
|
|
//
|
|
|
|
|
// The chunk index must be valid or this method may throw.
|
2020-08-25 12:34:02 -04:00
|
|
|
func (p *pageAlloc) chunkOf(ci chunkIdx) *pallocData {
|
|
|
|
|
return &p.chunks[ci.l1()][ci.l2()]
|
2019-11-14 23:58:50 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// grow sets up the metadata for the address range [base, base+size).
|
2020-08-25 12:34:02 -04:00
|
|
|
// It may allocate metadata, in which case *p.sysStat will be updated.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
|
|
|
|
func (p *pageAlloc) grow(base, size uintptr) {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// Round up to chunks, since we can't deal with increments smaller
|
|
|
|
|
// than chunks. Also, sysGrow expects aligned values.
|
|
|
|
|
limit := alignUp(base+size, pallocChunkBytes)
|
|
|
|
|
base = alignDown(base, pallocChunkBytes)
|
|
|
|
|
|
|
|
|
|
// Grow the summary levels in a system-dependent manner.
|
|
|
|
|
// We just update a bunch of additional metadata here.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.sysGrow(base, limit)
|
2019-08-14 16:32:12 +00:00
|
|
|
|
2023-04-20 02:41:08 +00:00
|
|
|
// Grow the scavenge index.
|
|
|
|
|
p.summaryMappedReady += p.scav.index.grow(base, limit, p.sysStat)
|
|
|
|
|
|
2020-08-25 12:34:02 -04:00
|
|
|
// Update p.start and p.end.
|
2019-08-14 16:32:12 +00:00
|
|
|
// If no growth happened yet, start == 0. This is generally
|
|
|
|
|
// safe since the zero page is unmapped.
|
2020-08-25 12:34:02 -04:00
|
|
|
firstGrowth := p.start == 0
|
2019-08-14 16:32:12 +00:00
|
|
|
start, end := chunkIndex(base), chunkIndex(limit)
|
2020-08-25 12:34:02 -04:00
|
|
|
if firstGrowth || start < p.start {
|
|
|
|
|
p.start = start
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
if end > p.end {
|
|
|
|
|
p.end = end
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2019-11-15 23:30:30 +00:00
|
|
|
// Note that [base, limit) will never overlap with any existing
|
|
|
|
|
// range inUse because grow only ever adds never-used memory
|
|
|
|
|
// regions to the page allocator.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.inUse.add(makeAddrRange(base, limit))
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// A grow operation is a lot like a free operation, so if our
|
2020-08-25 12:34:02 -04:00
|
|
|
// chunk ends up below p.searchAddr, update p.searchAddr to the
|
2020-04-28 21:30:57 +00:00
|
|
|
// new address, just like in free.
|
2020-08-25 12:34:02 -04:00
|
|
|
if b := (offAddr{base}); b.lessThan(p.searchAddr) {
|
|
|
|
|
p.searchAddr = b
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2019-11-14 23:58:50 +00:00
|
|
|
// Add entries into chunks, which is sparse, if needed. Then,
|
|
|
|
|
// initialize the bitmap.
|
2019-08-21 00:24:25 +00:00
|
|
|
//
|
2019-11-14 23:58:50 +00:00
|
|
|
// Newly-grown memory is always considered scavenged.
|
2019-08-21 00:24:25 +00:00
|
|
|
// Set all the bits in the scavenged bitmaps high.
|
|
|
|
|
for c := chunkIndex(base); c < chunkIndex(limit); c++ {
|
2020-08-25 12:34:02 -04:00
|
|
|
if p.chunks[c.l1()] == nil {
|
2019-11-14 23:58:50 +00:00
|
|
|
// Create the necessary l2 entry.
|
2023-01-03 17:59:48 +00:00
|
|
|
const l2Size = unsafe.Sizeof(*p.chunks[0])
|
2025-02-01 14:19:04 +01:00
|
|
|
r := sysAlloc(l2Size, p.sysStat, vmaNamePageAllocIndex)
|
2021-03-30 12:21:20 -07:00
|
|
|
if r == nil {
|
|
|
|
|
throw("pageAlloc: out of memory")
|
|
|
|
|
}
|
2023-01-03 17:59:48 +00:00
|
|
|
if !p.test {
|
|
|
|
|
// Make the chunk mapping eligible or ineligible
|
|
|
|
|
// for huge pages, depending on what our current
|
|
|
|
|
// state is.
|
|
|
|
|
if p.chunkHugePages {
|
|
|
|
|
sysHugePage(r, l2Size)
|
|
|
|
|
} else {
|
|
|
|
|
sysNoHugePage(r, l2Size)
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-09-07 20:03:25 +00:00
|
|
|
// Store the new chunk block but avoid a write barrier.
|
|
|
|
|
// grow is used in call chains that disallow write barriers.
|
|
|
|
|
*(*uintptr)(unsafe.Pointer(&p.chunks[c.l1()])) = uintptr(r)
|
2019-11-14 23:58:50 +00:00
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.chunkOf(c).scavenged.setRange(0, pallocChunkPages)
|
2019-08-21 00:24:25 +00:00
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// Update summaries accordingly. The grow acts like a free, so
|
|
|
|
|
// we need to ensure this newly-free memory is visible in the
|
|
|
|
|
// summaries.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.update(base, size/pageSize, true, false)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2023-01-03 17:59:48 +00:00
|
|
|
// enableChunkHugePages enables huge pages for the chunk bitmap mappings (disabled by default).
|
|
|
|
|
//
|
|
|
|
|
// This function is idempotent.
|
|
|
|
|
//
|
|
|
|
|
// A note on latency: for sufficiently small heaps (<10s of GiB) this function will take constant
|
|
|
|
|
// time, but may take time proportional to the size of the mapped heap beyond that.
|
|
|
|
|
//
|
|
|
|
|
// The heap lock must not be held over this operation, since it will briefly acquire
|
|
|
|
|
// the heap lock.
|
2023-11-10 21:23:38 +00:00
|
|
|
//
|
|
|
|
|
// Must be called on the system stack because it acquires the heap lock.
|
|
|
|
|
//
|
|
|
|
|
//go:systemstack
|
2023-01-03 17:59:48 +00:00
|
|
|
func (p *pageAlloc) enableChunkHugePages() {
|
|
|
|
|
// Grab the heap lock to turn on huge pages for new chunks and clone the current
|
|
|
|
|
// heap address space ranges.
|
|
|
|
|
//
|
|
|
|
|
// After the lock is released, we can be sure that bitmaps for any new chunks may
|
|
|
|
|
// be backed with huge pages, and we have the address space for the rest of the
|
|
|
|
|
// chunks. At the end of this function, all chunk metadata should be backed by huge
|
|
|
|
|
// pages.
|
|
|
|
|
lock(&mheap_.lock)
|
|
|
|
|
if p.chunkHugePages {
|
|
|
|
|
unlock(&mheap_.lock)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
p.chunkHugePages = true
|
|
|
|
|
var inUse addrRanges
|
|
|
|
|
inUse.sysStat = p.sysStat
|
|
|
|
|
p.inUse.cloneInto(&inUse)
|
|
|
|
|
unlock(&mheap_.lock)
|
|
|
|
|
|
|
|
|
|
// This might seem like a lot of work, but all these loops are for generality.
|
|
|
|
|
//
|
|
|
|
|
// For a 1 GiB contiguous heap, a 48-bit address space, 13 L1 bits, a palloc chunk size
|
|
|
|
|
// of 4 MiB, and adherence to the default set of heap address hints, this will result in
|
|
|
|
|
// exactly 1 call to sysHugePage.
|
|
|
|
|
for _, r := range p.inUse.ranges {
|
|
|
|
|
for i := chunkIndex(r.base.addr()).l1(); i < chunkIndex(r.limit.addr()-1).l1(); i++ {
|
|
|
|
|
// N.B. We can assume that p.chunks[i] is non-nil and in a mapped part of p.chunks
|
|
|
|
|
// because it's derived from inUse, which never shrinks.
|
|
|
|
|
sysHugePage(unsafe.Pointer(p.chunks[i]), unsafe.Sizeof(*p.chunks[0]))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// update updates heap metadata. It must be called each time the bitmap
|
|
|
|
|
// is updated.
|
|
|
|
|
//
|
|
|
|
|
// If contig is true, update does some optimizations assuming that there was
|
|
|
|
|
// a contiguous allocation or free between addr and addr+npages. alloc indicates
|
|
|
|
|
// whether the operation performed was an allocation or a free.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
|
|
|
|
func (p *pageAlloc) update(base, npages uintptr, contig, alloc bool) {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// base, limit, start, and end are inclusive.
|
|
|
|
|
limit := base + npages*pageSize - 1
|
|
|
|
|
sc, ec := chunkIndex(base), chunkIndex(limit)
|
|
|
|
|
|
|
|
|
|
// Handle updating the lowest level first.
|
|
|
|
|
if sc == ec {
|
|
|
|
|
// Fast path: the allocation doesn't span more than one chunk,
|
|
|
|
|
// so update this one and if the summary didn't change, return.
|
2020-08-25 12:34:02 -04:00
|
|
|
x := p.summary[len(p.summary)-1][sc]
|
|
|
|
|
y := p.chunkOf(sc).summarize()
|
2019-08-14 16:32:12 +00:00
|
|
|
if x == y {
|
|
|
|
|
return
|
|
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.summary[len(p.summary)-1][sc] = y
|
2019-08-14 16:32:12 +00:00
|
|
|
} else if contig {
|
|
|
|
|
// Slow contiguous path: the allocation spans more than one chunk
|
|
|
|
|
// and at least one summary is guaranteed to change.
|
2020-08-25 12:34:02 -04:00
|
|
|
summary := p.summary[len(p.summary)-1]
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Update the summary for chunk sc.
|
2020-08-25 12:34:02 -04:00
|
|
|
summary[sc] = p.chunkOf(sc).summarize()
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Update the summaries for chunks in between, which are
|
|
|
|
|
// either totally allocated or freed.
|
2020-08-25 12:34:02 -04:00
|
|
|
whole := p.summary[len(p.summary)-1][sc+1 : ec]
|
2019-08-14 16:32:12 +00:00
|
|
|
if alloc {
|
2024-03-08 10:12:41 +00:00
|
|
|
clear(whole)
|
2019-08-14 16:32:12 +00:00
|
|
|
} else {
|
|
|
|
|
for i := range whole {
|
|
|
|
|
whole[i] = freeChunkSum
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Update the summary for chunk ec.
|
2020-08-25 12:34:02 -04:00
|
|
|
summary[ec] = p.chunkOf(ec).summarize()
|
2019-08-14 16:32:12 +00:00
|
|
|
} else {
|
|
|
|
|
// Slow general path: the allocation spans more than one chunk
|
|
|
|
|
// and at least one summary is guaranteed to change.
|
|
|
|
|
//
|
|
|
|
|
// We can't assume a contiguous allocation happened, so walk over
|
|
|
|
|
// every chunk in the range and manually recompute the summary.
|
2020-08-25 12:34:02 -04:00
|
|
|
summary := p.summary[len(p.summary)-1]
|
2019-08-14 16:32:12 +00:00
|
|
|
for c := sc; c <= ec; c++ {
|
2020-08-25 12:34:02 -04:00
|
|
|
summary[c] = p.chunkOf(c).summarize()
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Walk up the radix tree and update the summaries appropriately.
|
|
|
|
|
changed := true
|
2020-08-25 12:34:02 -04:00
|
|
|
for l := len(p.summary) - 2; l >= 0 && changed; l-- {
|
2019-08-14 16:32:12 +00:00
|
|
|
// Update summaries at level l from summaries at level l+1.
|
|
|
|
|
changed = false
|
|
|
|
|
|
|
|
|
|
// "Constants" for the previous level which we
|
|
|
|
|
// need to compute the summary from that level.
|
|
|
|
|
logEntriesPerBlock := levelBits[l+1]
|
|
|
|
|
logMaxPages := levelLogPages[l+1]
|
|
|
|
|
|
|
|
|
|
// lo and hi describe all the parts of the level we need to look at.
|
|
|
|
|
lo, hi := addrsToSummaryRange(l, base, limit+1)
|
|
|
|
|
|
|
|
|
|
// Iterate over each block, updating the corresponding summary in the less-granular level.
|
|
|
|
|
for i := lo; i < hi; i++ {
|
2020-08-25 12:34:02 -04:00
|
|
|
children := p.summary[l+1][i<<logEntriesPerBlock : (i+1)<<logEntriesPerBlock]
|
2019-08-14 16:32:12 +00:00
|
|
|
sum := mergeSummaries(children, logMaxPages)
|
2020-08-25 12:34:02 -04:00
|
|
|
old := p.summary[l][i]
|
2019-08-14 16:32:12 +00:00
|
|
|
if old != sum {
|
|
|
|
|
changed = true
|
2020-08-25 12:34:02 -04:00
|
|
|
p.summary[l][i] = sum
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// allocRange marks the range of memory [base, base+npages*pageSize) as
|
|
|
|
|
// allocated. It also updates the summaries to reflect the newly-updated
|
|
|
|
|
// bitmap.
|
|
|
|
|
//
|
2019-09-10 18:53:51 +00:00
|
|
|
// Returns the amount of scavenged memory in bytes present in the
|
|
|
|
|
// allocated range.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
|
|
|
|
func (p *pageAlloc) allocRange(base, npages uintptr) uintptr {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
limit := base + npages*pageSize - 1
|
|
|
|
|
sc, ec := chunkIndex(base), chunkIndex(limit)
|
|
|
|
|
si, ei := chunkPageIndex(base), chunkPageIndex(limit)
|
|
|
|
|
|
2019-09-10 18:53:51 +00:00
|
|
|
scav := uint(0)
|
2019-08-14 16:32:12 +00:00
|
|
|
if sc == ec {
|
|
|
|
|
// The range doesn't cross any chunk boundaries.
|
2020-08-25 12:34:02 -04:00
|
|
|
chunk := p.chunkOf(sc)
|
2019-11-14 23:58:50 +00:00
|
|
|
scav += chunk.scavenged.popcntRange(si, ei+1-si)
|
|
|
|
|
chunk.allocRange(si, ei+1-si)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.alloc(sc, ei+1-si)
|
2019-08-14 16:32:12 +00:00
|
|
|
} else {
|
|
|
|
|
// The range crosses at least one chunk boundary.
|
2020-08-25 12:34:02 -04:00
|
|
|
chunk := p.chunkOf(sc)
|
2019-11-14 23:58:50 +00:00
|
|
|
scav += chunk.scavenged.popcntRange(si, pallocChunkPages-si)
|
|
|
|
|
chunk.allocRange(si, pallocChunkPages-si)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.alloc(sc, pallocChunkPages-si)
|
2019-08-14 16:32:12 +00:00
|
|
|
for c := sc + 1; c < ec; c++ {
|
2020-08-25 12:34:02 -04:00
|
|
|
chunk := p.chunkOf(c)
|
2019-11-14 23:58:50 +00:00
|
|
|
scav += chunk.scavenged.popcntRange(0, pallocChunkPages)
|
|
|
|
|
chunk.allocAll()
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.alloc(c, pallocChunkPages)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
chunk = p.chunkOf(ec)
|
2019-11-14 23:58:50 +00:00
|
|
|
scav += chunk.scavenged.popcntRange(0, ei+1)
|
|
|
|
|
chunk.allocRange(0, ei+1)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.alloc(ec, ei+1)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.update(base, npages, true, true)
|
2019-09-10 18:53:51 +00:00
|
|
|
return uintptr(scav) * pageSize
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2020-07-13 19:51:50 +00:00
|
|
|
// findMappedAddr returns the smallest mapped offAddr that is
|
|
|
|
|
// >= addr. That is, if addr refers to mapped memory, then it is
|
|
|
|
|
// returned. If addr is higher than any mapped region, then
|
|
|
|
|
// it returns maxOffAddr.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
|
|
|
|
func (p *pageAlloc) findMappedAddr(addr offAddr) offAddr {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2020-07-13 19:51:50 +00:00
|
|
|
// If we're not in a test, validate first by checking mheap_.arenas.
|
|
|
|
|
// This is a fast path which is only safe to use outside of testing.
|
|
|
|
|
ai := arenaIndex(addr.addr())
|
2020-08-25 12:34:02 -04:00
|
|
|
if p.test || mheap_.arenas[ai.l1()] == nil || mheap_.arenas[ai.l1()][ai.l2()] == nil {
|
|
|
|
|
vAddr, ok := p.inUse.findAddrGreaterEqual(addr.addr())
|
2020-07-13 19:51:50 +00:00
|
|
|
if ok {
|
|
|
|
|
return offAddr{vAddr}
|
|
|
|
|
} else {
|
|
|
|
|
// The candidate search address is greater than any
|
|
|
|
|
// known address, which means we definitely have no
|
|
|
|
|
// free memory left.
|
|
|
|
|
return maxOffAddr
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return addr
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// find searches for the first (address-ordered) contiguous free region of
|
|
|
|
|
// npages in size and returns a base address for that region.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// It uses p.searchAddr to prune its search and assumes that no palloc chunks
|
|
|
|
|
// below chunkIndex(p.searchAddr) contain any free memory at all.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// find also computes and returns a candidate p.searchAddr, which may or
|
|
|
|
|
// may not prune more of the address space than p.searchAddr already does.
|
|
|
|
|
// This candidate is always a valid p.searchAddr.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
|
|
|
|
// find represents the slow path and the full radix tree search.
|
|
|
|
|
//
|
|
|
|
|
// Returns a base address of 0 on failure, in which case the candidate
|
|
|
|
|
// searchAddr returned is invalid and must be ignored.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
|
|
|
|
func (p *pageAlloc) find(npages uintptr) (uintptr, offAddr) {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// Search algorithm.
|
|
|
|
|
//
|
|
|
|
|
// This algorithm walks each level l of the radix tree from the root level
|
|
|
|
|
// to the leaf level. It iterates over at most 1 << levelBits[l] of entries
|
|
|
|
|
// in a given level in the radix tree, and uses the summary information to
|
|
|
|
|
// find either:
|
|
|
|
|
// 1) That a given subtree contains a large enough contiguous region, at
|
|
|
|
|
// which point it continues iterating on the next level, or
|
|
|
|
|
// 2) That there are enough contiguous boundary-crossing bits to satisfy
|
|
|
|
|
// the allocation, at which point it knows exactly where to start
|
|
|
|
|
// allocating from.
|
|
|
|
|
//
|
|
|
|
|
// i tracks the index into the current level l's structure for the
|
|
|
|
|
// contiguous 1 << levelBits[l] entries we're actually interested in.
|
|
|
|
|
//
|
|
|
|
|
// NOTE: Technically this search could allocate a region which crosses
|
|
|
|
|
// the arenaBaseOffset boundary, which when arenaBaseOffset != 0, is
|
|
|
|
|
// a discontinuity. However, the only way this could happen is if the
|
|
|
|
|
// page at the zero address is mapped, and this is impossible on
|
|
|
|
|
// every system we support where arenaBaseOffset != 0. So, the
|
|
|
|
|
// discontinuity is already encoded in the fact that the OS will never
|
|
|
|
|
// map the zero page for us, and this function doesn't try to handle
|
|
|
|
|
// this case in any way.
|
|
|
|
|
|
|
|
|
|
// i is the beginning of the block of entries we're searching at the
|
|
|
|
|
// current level.
|
|
|
|
|
i := 0
|
|
|
|
|
|
|
|
|
|
// firstFree is the region of address space that we are certain to
|
|
|
|
|
// find the first free page in the heap. base and bound are the inclusive
|
|
|
|
|
// bounds of this window, and both are addresses in the linearized, contiguous
|
|
|
|
|
// view of the address space (with arenaBaseOffset pre-added). At each level,
|
|
|
|
|
// this window is narrowed as we find the memory region containing the
|
|
|
|
|
// first free page of memory. To begin with, the range reflects the
|
|
|
|
|
// full process address space.
|
|
|
|
|
//
|
|
|
|
|
// firstFree is updated by calling foundFree each time free space in the
|
|
|
|
|
// heap is discovered.
|
|
|
|
|
//
|
2020-04-28 21:30:57 +00:00
|
|
|
// At the end of the search, base.addr() is the best new
|
2019-08-14 16:32:12 +00:00
|
|
|
// searchAddr we could deduce in this search.
|
|
|
|
|
firstFree := struct {
|
2020-04-28 21:30:57 +00:00
|
|
|
base, bound offAddr
|
2019-08-14 16:32:12 +00:00
|
|
|
}{
|
2020-04-28 21:30:57 +00:00
|
|
|
base: minOffAddr,
|
|
|
|
|
bound: maxOffAddr,
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
// foundFree takes the given address range [addr, addr+size) and
|
|
|
|
|
// updates firstFree if it is a narrower range. The input range must
|
|
|
|
|
// either be fully contained within firstFree or not overlap with it
|
|
|
|
|
// at all.
|
|
|
|
|
//
|
|
|
|
|
// This way, we'll record the first summary we find with any free
|
|
|
|
|
// pages on the root level and narrow that down if we descend into
|
|
|
|
|
// that summary. But as soon as we need to iterate beyond that summary
|
|
|
|
|
// in a level to find a large enough range, we'll stop narrowing.
|
2020-04-28 21:30:57 +00:00
|
|
|
foundFree := func(addr offAddr, size uintptr) {
|
|
|
|
|
if firstFree.base.lessEqual(addr) && addr.add(size-1).lessEqual(firstFree.bound) {
|
2019-08-14 16:32:12 +00:00
|
|
|
// This range fits within the current firstFree window, so narrow
|
|
|
|
|
// down the firstFree window to the base and bound of this range.
|
|
|
|
|
firstFree.base = addr
|
2020-04-28 21:30:57 +00:00
|
|
|
firstFree.bound = addr.add(size - 1)
|
|
|
|
|
} else if !(addr.add(size-1).lessThan(firstFree.base) || firstFree.bound.lessThan(addr)) {
|
2019-08-14 16:32:12 +00:00
|
|
|
// This range only partially overlaps with the firstFree range,
|
|
|
|
|
// so throw.
|
2020-04-28 21:30:57 +00:00
|
|
|
print("runtime: addr = ", hex(addr.addr()), ", size = ", size, "\n")
|
|
|
|
|
print("runtime: base = ", hex(firstFree.base.addr()), ", bound = ", hex(firstFree.bound.addr()), "\n")
|
2019-08-14 16:32:12 +00:00
|
|
|
throw("range partially overlaps")
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// lastSum is the summary which we saw on the previous level that made us
|
|
|
|
|
// move on to the next level. Used to print additional information in the
|
|
|
|
|
// case of a catastrophic failure.
|
|
|
|
|
// lastSumIdx is that summary's index in the previous level.
|
|
|
|
|
lastSum := packPallocSum(0, 0, 0)
|
|
|
|
|
lastSumIdx := -1
|
|
|
|
|
|
|
|
|
|
nextLevel:
|
2020-08-25 12:34:02 -04:00
|
|
|
for l := 0; l < len(p.summary); l++ {
|
2019-08-14 16:32:12 +00:00
|
|
|
// For the root level, entriesPerBlock is the whole level.
|
|
|
|
|
entriesPerBlock := 1 << levelBits[l]
|
|
|
|
|
logMaxPages := levelLogPages[l]
|
|
|
|
|
|
|
|
|
|
// We've moved into a new level, so let's update i to our new
|
|
|
|
|
// starting index. This is a no-op for level 0.
|
|
|
|
|
i <<= levelBits[l]
|
|
|
|
|
|
|
|
|
|
// Slice out the block of entries we care about.
|
2020-08-25 12:34:02 -04:00
|
|
|
entries := p.summary[l][i : i+entriesPerBlock]
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Determine j0, the first index we should start iterating from.
|
|
|
|
|
// The searchAddr may help us eliminate iterations if we followed the
|
2022-08-31 08:28:13 +00:00
|
|
|
// searchAddr on the previous level or we're on the root level, in which
|
2019-08-14 16:32:12 +00:00
|
|
|
// case the searchAddr should be the same as i after levelShift.
|
|
|
|
|
j0 := 0
|
2020-08-25 12:34:02 -04:00
|
|
|
if searchIdx := offAddrToLevelIndex(l, p.searchAddr); searchIdx&^(entriesPerBlock-1) == i {
|
2019-08-14 16:32:12 +00:00
|
|
|
j0 = searchIdx & (entriesPerBlock - 1)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Run over the level entries looking for
|
|
|
|
|
// a contiguous run of at least npages either
|
|
|
|
|
// within an entry or across entries.
|
|
|
|
|
//
|
|
|
|
|
// base contains the page index (relative to
|
|
|
|
|
// the first entry's first page) of the currently
|
|
|
|
|
// considered run of consecutive pages.
|
|
|
|
|
//
|
|
|
|
|
// size contains the size of the currently considered
|
|
|
|
|
// run of consecutive pages.
|
|
|
|
|
var base, size uint
|
|
|
|
|
for j := j0; j < len(entries); j++ {
|
|
|
|
|
sum := entries[j]
|
|
|
|
|
if sum == 0 {
|
|
|
|
|
// A full entry means we broke any streak and
|
|
|
|
|
// that we should skip it altogether.
|
|
|
|
|
size = 0
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// We've encountered a non-zero summary which means
|
|
|
|
|
// free memory, so update firstFree.
|
2020-04-28 21:30:57 +00:00
|
|
|
foundFree(levelIndexToOffAddr(l, i+j), (uintptr(1)<<logMaxPages)*pageSize)
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
s := sum.start()
|
|
|
|
|
if size+s >= uint(npages) {
|
|
|
|
|
// If size == 0 we don't have a run yet,
|
|
|
|
|
// which means base isn't valid. So, set
|
|
|
|
|
// base to the first page in this block.
|
|
|
|
|
if size == 0 {
|
|
|
|
|
base = uint(j) << logMaxPages
|
|
|
|
|
}
|
|
|
|
|
// We hit npages; we're done!
|
|
|
|
|
size += s
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
if sum.max() >= uint(npages) {
|
|
|
|
|
// The entry itself contains npages contiguous
|
|
|
|
|
// free pages, so continue on the next level
|
|
|
|
|
// to find that run.
|
|
|
|
|
i += j
|
|
|
|
|
lastSumIdx = i
|
|
|
|
|
lastSum = sum
|
|
|
|
|
continue nextLevel
|
|
|
|
|
}
|
|
|
|
|
if size == 0 || s < 1<<logMaxPages {
|
|
|
|
|
// We either don't have a current run started, or this entry
|
|
|
|
|
// isn't totally free (meaning we can't continue the current
|
|
|
|
|
// one), so try to begin a new run by setting size and base
|
|
|
|
|
// based on sum.end.
|
|
|
|
|
size = sum.end()
|
|
|
|
|
base = uint(j+1)<<logMaxPages - size
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
// The entry is completely free, so continue the run.
|
|
|
|
|
size += 1 << logMaxPages
|
|
|
|
|
}
|
|
|
|
|
if size >= uint(npages) {
|
|
|
|
|
// We found a sufficiently large run of free pages straddling
|
|
|
|
|
// some boundary, so compute the address and return it.
|
2020-04-28 21:30:57 +00:00
|
|
|
addr := levelIndexToOffAddr(l, i).add(uintptr(base) * pageSize).addr()
|
2020-08-25 12:34:02 -04:00
|
|
|
return addr, p.findMappedAddr(firstFree.base)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
if l == 0 {
|
|
|
|
|
// We're at level zero, so that means we've exhausted our search.
|
2022-03-28 09:30:41 -07:00
|
|
|
return 0, maxSearchAddr()
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// We're not at level zero, and we exhausted the level we were looking in.
|
|
|
|
|
// This means that either our calculations were wrong or the level above
|
|
|
|
|
// lied to us. In either case, dump some useful state and throw.
|
|
|
|
|
print("runtime: summary[", l-1, "][", lastSumIdx, "] = ", lastSum.start(), ", ", lastSum.max(), ", ", lastSum.end(), "\n")
|
|
|
|
|
print("runtime: level = ", l, ", npages = ", npages, ", j0 = ", j0, "\n")
|
2020-08-25 12:34:02 -04:00
|
|
|
print("runtime: p.searchAddr = ", hex(p.searchAddr.addr()), ", i = ", i, "\n")
|
2019-08-14 16:32:12 +00:00
|
|
|
print("runtime: levelShift[level] = ", levelShift[l], ", levelBits[level] = ", levelBits[l], "\n")
|
|
|
|
|
for j := 0; j < len(entries); j++ {
|
|
|
|
|
sum := entries[j]
|
|
|
|
|
print("runtime: summary[", l, "][", i+j, "] = (", sum.start(), ", ", sum.max(), ", ", sum.end(), ")\n")
|
|
|
|
|
}
|
|
|
|
|
throw("bad summary data")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Since we've gotten to this point, that means we haven't found a
|
|
|
|
|
// sufficiently-sized free region straddling some boundary (chunk or larger).
|
|
|
|
|
// This means the last summary we inspected must have had a large enough "max"
|
|
|
|
|
// value, so look inside the chunk to find a suitable run.
|
|
|
|
|
//
|
|
|
|
|
// After iterating over all levels, i must contain a chunk index which
|
|
|
|
|
// is what the final level represents.
|
|
|
|
|
ci := chunkIdx(i)
|
2020-08-25 12:34:02 -04:00
|
|
|
j, searchIdx := p.chunkOf(ci).find(npages, 0)
|
2020-03-28 16:11:15 +00:00
|
|
|
if j == ^uint(0) {
|
2019-08-14 16:32:12 +00:00
|
|
|
// We couldn't find any space in this chunk despite the summaries telling
|
|
|
|
|
// us it should be there. There's likely a bug, so dump some state and throw.
|
2020-08-25 12:34:02 -04:00
|
|
|
sum := p.summary[len(p.summary)-1][i]
|
|
|
|
|
print("runtime: summary[", len(p.summary)-1, "][", i, "] = (", sum.start(), ", ", sum.max(), ", ", sum.end(), ")\n")
|
2019-08-14 16:32:12 +00:00
|
|
|
print("runtime: npages = ", npages, "\n")
|
|
|
|
|
throw("bad summary data")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Compute the address at which the free space starts.
|
|
|
|
|
addr := chunkBase(ci) + uintptr(j)*pageSize
|
|
|
|
|
|
|
|
|
|
// Since we actually searched the chunk, we may have
|
|
|
|
|
// found an even narrower free window.
|
|
|
|
|
searchAddr := chunkBase(ci) + uintptr(searchIdx)*pageSize
|
2020-04-28 21:30:57 +00:00
|
|
|
foundFree(offAddr{searchAddr}, chunkBase(ci+1)-searchAddr)
|
2020-08-25 12:34:02 -04:00
|
|
|
return addr, p.findMappedAddr(firstFree.base)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// alloc allocates npages worth of memory from the page heap, returning the base
|
2019-09-10 18:53:51 +00:00
|
|
|
// address for the allocation and the amount of scavenged memory in bytes
|
|
|
|
|
// contained in the region [base address, base address + npages*pageSize).
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2019-09-10 18:53:51 +00:00
|
|
|
// Returns a 0 base address on failure, in which case other returned values
|
|
|
|
|
// should be ignored.
|
2019-08-14 16:32:12 +00:00
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
2020-08-21 11:59:55 -04:00
|
|
|
//
|
|
|
|
|
// Must run on the system stack because p.mheapLock must be held.
|
|
|
|
|
//
|
|
|
|
|
//go:systemstack
|
2020-08-25 12:34:02 -04:00
|
|
|
func (p *pageAlloc) alloc(npages uintptr) (addr uintptr, scav uintptr) {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2019-08-14 16:32:12 +00:00
|
|
|
// If the searchAddr refers to a region which has a higher address than
|
|
|
|
|
// any known chunk, then we know we're out of memory.
|
2020-08-25 12:34:02 -04:00
|
|
|
if chunkIndex(p.searchAddr.addr()) >= p.end {
|
2019-09-10 18:53:51 +00:00
|
|
|
return 0, 0
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If npages has a chance of fitting in the chunk where the searchAddr is,
|
|
|
|
|
// search it directly.
|
2020-04-28 21:30:57 +00:00
|
|
|
searchAddr := minOffAddr
|
2020-08-25 12:34:02 -04:00
|
|
|
if pallocChunkPages-chunkPageIndex(p.searchAddr.addr()) >= uint(npages) {
|
2019-08-14 16:32:12 +00:00
|
|
|
// npages is guaranteed to be no greater than pallocChunkPages here.
|
2020-08-25 12:34:02 -04:00
|
|
|
i := chunkIndex(p.searchAddr.addr())
|
|
|
|
|
if max := p.summary[len(p.summary)-1][i].max(); max >= uint(npages) {
|
|
|
|
|
j, searchIdx := p.chunkOf(i).find(npages, chunkPageIndex(p.searchAddr.addr()))
|
2020-03-28 16:11:15 +00:00
|
|
|
if j == ^uint(0) {
|
2019-08-14 16:32:12 +00:00
|
|
|
print("runtime: max = ", max, ", npages = ", npages, "\n")
|
2020-08-25 12:34:02 -04:00
|
|
|
print("runtime: searchIdx = ", chunkPageIndex(p.searchAddr.addr()), ", p.searchAddr = ", hex(p.searchAddr.addr()), "\n")
|
2019-08-14 16:32:12 +00:00
|
|
|
throw("bad summary data")
|
|
|
|
|
}
|
|
|
|
|
addr = chunkBase(i) + uintptr(j)*pageSize
|
2020-04-28 21:30:57 +00:00
|
|
|
searchAddr = offAddr{chunkBase(i) + uintptr(searchIdx)*pageSize}
|
2019-08-14 16:32:12 +00:00
|
|
|
goto Found
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// We failed to use a searchAddr for one reason or another, so try
|
|
|
|
|
// the slow path.
|
2020-08-25 12:34:02 -04:00
|
|
|
addr, searchAddr = p.find(npages)
|
2019-08-14 16:32:12 +00:00
|
|
|
if addr == 0 {
|
|
|
|
|
if npages == 1 {
|
|
|
|
|
// We failed to find a single free page, the smallest unit
|
|
|
|
|
// of allocation. This means we know the heap is completely
|
|
|
|
|
// exhausted. Otherwise, the heap still might have free
|
|
|
|
|
// space in it, just not enough contiguous space to
|
|
|
|
|
// accommodate npages.
|
2022-03-28 09:30:41 -07:00
|
|
|
p.searchAddr = maxSearchAddr()
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2019-09-10 18:53:51 +00:00
|
|
|
return 0, 0
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
Found:
|
|
|
|
|
// Go ahead and actually mark the bits now that we have an address.
|
2020-08-25 12:34:02 -04:00
|
|
|
scav = p.allocRange(addr, npages)
|
2019-08-14 16:32:12 +00:00
|
|
|
|
2020-04-28 21:30:57 +00:00
|
|
|
// If we found a higher searchAddr, we know that all the
|
|
|
|
|
// heap memory before that searchAddr in an offset address space is
|
2020-08-25 12:34:02 -04:00
|
|
|
// allocated, so bump p.searchAddr up to the new one.
|
|
|
|
|
if p.searchAddr.lessThan(searchAddr) {
|
|
|
|
|
p.searchAddr = searchAddr
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2019-09-10 18:53:51 +00:00
|
|
|
return addr, scav
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// free returns npages worth of memory starting at base back to the page heap.
|
|
|
|
|
//
|
2020-08-25 12:34:02 -04:00
|
|
|
// p.mheapLock must be held.
|
2020-08-21 11:59:55 -04:00
|
|
|
//
|
|
|
|
|
// Must run on the system stack because p.mheapLock must be held.
|
|
|
|
|
//
|
|
|
|
|
//go:systemstack
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
func (p *pageAlloc) free(base, npages uintptr) {
|
2020-08-21 11:59:55 -04:00
|
|
|
assertLockHeld(p.mheapLock)
|
|
|
|
|
|
2020-08-25 12:34:02 -04:00
|
|
|
// If we're freeing pages below the p.searchAddr, update searchAddr.
|
|
|
|
|
if b := (offAddr{base}); b.lessThan(p.searchAddr) {
|
|
|
|
|
p.searchAddr = b
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
runtime: avoid re-scanning scavenged and untouched memory
Currently the scavenger will reset to the top of the heap every GC. This
means if it scavenges a bunch of memory which doesn't get used again,
it's going to keep re-scanning that memory on subsequent cycles. This
problem is especially bad when it comes to heap spikes: suppose an
application's heap spikes to 2x its steady-state size. The scavenger
will run over the top half of that heap even if the heap shrinks, for
the rest of the application's lifetime.
To fix this, we maintain two numbers: a "free" high watermark, which
represents the highest address freed to the page allocator in that
cycle, and a "scavenged" low watermark, which represents how low of an
address the scavenger got to when scavenging. If the "free" watermark
exceeds the "scavenged" watermark, then we pick the "free" watermark as
the new "top of the heap" for the scavenger when starting the next
scavenger cycle. Otherwise, we have the scavenger pick up where it left
off.
With this mechanism, we only ever re-scan scavenged memory if a random
page gets freed very high up in the heap address space while most of the
action is happening in the lower parts. This case should be exceedingly
unlikely because the page reclaimer walks over the heap from low address
to high addresses, and we use a first-fit address-ordered allocation
policy.
Updates #35788.
Change-Id: Id335603b526ce3a0eb79ef286d1a4e876abc9cab
Reviewed-on: https://go-review.googlesource.com/c/go/+/218997
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
2020-02-10 23:11:30 +00:00
|
|
|
limit := base + npages*pageSize - 1
|
2019-08-14 16:32:12 +00:00
|
|
|
if npages == 1 {
|
|
|
|
|
// Fast path: we're clearing a single bit, and we know exactly
|
|
|
|
|
// where it is, so mark it directly.
|
2019-11-14 23:58:50 +00:00
|
|
|
i := chunkIndex(base)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
pi := chunkPageIndex(base)
|
|
|
|
|
p.chunkOf(i).free1(pi)
|
|
|
|
|
p.scav.index.free(i, pi, 1)
|
2019-08-14 16:32:12 +00:00
|
|
|
} else {
|
|
|
|
|
// Slow path: we're clearing more bits so we may need to iterate.
|
|
|
|
|
sc, ec := chunkIndex(base), chunkIndex(limit)
|
|
|
|
|
si, ei := chunkPageIndex(base), chunkPageIndex(limit)
|
|
|
|
|
|
|
|
|
|
if sc == ec {
|
|
|
|
|
// The range doesn't cross any chunk boundaries.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.chunkOf(sc).free(si, ei+1-si)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.free(sc, si, ei+1-si)
|
2019-08-14 16:32:12 +00:00
|
|
|
} else {
|
|
|
|
|
// The range crosses at least one chunk boundary.
|
2020-08-25 12:34:02 -04:00
|
|
|
p.chunkOf(sc).free(si, pallocChunkPages-si)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.free(sc, si, pallocChunkPages-si)
|
2019-08-14 16:32:12 +00:00
|
|
|
for c := sc + 1; c < ec; c++ {
|
2020-08-25 12:34:02 -04:00
|
|
|
p.chunkOf(c).freeAll()
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.free(c, 0, pallocChunkPages)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.chunkOf(ec).free(0, ei+1)
|
runtime: manage huge pages explicitly
This change makes it so that on Linux the Go runtime explicitly marks
page heap memory as either available to be backed by hugepages or not
using heuristics based on density.
The motivation behind this change is twofold:
1. In default Linux configurations, khugepaged can recoalesce hugepages
even after the scavenger breaks them up, resulting in significant
overheads for small heaps when their heaps shrink.
2. The Go runtime already has some heuristics about this, but those
heuristics appear to have bit-rotted and result in haphazard
hugepage management. Unlucky (but otherwise fairly dense) regions of
memory end up not backed by huge pages while sparse regions end up
accidentally marked MADV_HUGEPAGE and are not later broken up by the
scavenger, because it already got the memory it needed from more
dense sections (this is more likely to happen with small heaps that
go idle).
In this change, the runtime uses a new policy:
1. Mark all new memory MADV_HUGEPAGE.
2. Track whether each page chunk (4 MiB) became dense during the GC
cycle. Mark those MADV_HUGEPAGE, and hide them from the scavenger.
3. If a chunk is not dense for 1 full GC cycle, make it visible to the
scavenger.
4. The scavenger marks a chunk MADV_NOHUGEPAGE before it scavenges it.
This policy is intended to try and back memory that is a good candidate
for huge pages (high occupancy) with huge pages, and give memory that is
not (low occupancy) to the scavenger. Occupancy is defined not just by
occupancy at any instant of time, but also occupancy in the near future.
It's generally true that by the end of a GC cycle the heap gets quite
dense (from the perspective of the page allocator).
Because we want scavenging and huge page management to happen together
(the right time to MADV_NOHUGEPAGE is just before scavenging in order to
break up huge pages and keep them that way) and the cost of applying
MADV_HUGEPAGE and MADV_NOHUGEPAGE is somewhat high, the scavenger avoids
releasing memory in dense page chunks. All this together means the
scavenger will now more generally release memory on a ~1 GC cycle delay.
Notably this has implications for scavenging to maintain the memory
limit and the runtime/debug.FreeOSMemory API. This change makes it so
that in these cases all memory is visible to the scavenger regardless of
sparseness and delays the page allocator in re-marking this memory with
MADV_NOHUGEPAGE for around 1 GC cycle to mitigate churn.
The end result of this change should be little-to-no performance
difference for dense heaps (MADV_HUGEPAGE works a lot like the default
unmarked state) but should allow the scavenger to more effectively take
back fragments of huge pages. The main risk here is churn, because
MADV_HUGEPAGE usually forces the kernel to immediately back memory with
a huge page. That's the reason for the large amount of hysteresis (1
full GC cycle) and why the definition of high density is 96% occupancy.
Fixes #55328.
Change-Id: I8da7998f1a31b498a9cc9bc662c1ae1a6bf64630
Reviewed-on: https://go-review.googlesource.com/c/go/+/436395
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-23 16:32:34 +00:00
|
|
|
p.scav.index.free(ec, 0, ei+1)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
}
|
2020-08-25 12:34:02 -04:00
|
|
|
p.update(base, npages, true, false)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|
|
|
|
|
|
2019-09-25 15:55:29 +00:00
|
|
|
const (
|
2019-08-14 16:32:12 +00:00
|
|
|
pallocSumBytes = unsafe.Sizeof(pallocSum(0))
|
|
|
|
|
|
2019-09-25 15:55:29 +00:00
|
|
|
// maxPackedValue is the maximum value that any of the three fields in
|
|
|
|
|
// the pallocSum may take on.
|
|
|
|
|
maxPackedValue = 1 << logMaxPackedValue
|
|
|
|
|
logMaxPackedValue = logPallocChunkPages + (summaryLevels-1)*summaryLevelBits
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
freeChunkSum = pallocSum(uint64(pallocChunkPages) |
|
|
|
|
|
uint64(pallocChunkPages<<logMaxPackedValue) |
|
|
|
|
|
uint64(pallocChunkPages<<(2*logMaxPackedValue)))
|
2019-09-25 15:55:29 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// pallocSum is a packed summary type which packs three numbers: start, max,
|
|
|
|
|
// and end into a single 8-byte value. Each of these values are a summary of
|
|
|
|
|
// a bitmap and are thus counts, each of which may have a maximum value of
|
|
|
|
|
// 2^21 - 1, or all three may be equal to 2^21. The latter case is represented
|
|
|
|
|
// by just setting the 64th bit.
|
|
|
|
|
type pallocSum uint64
|
|
|
|
|
|
|
|
|
|
// packPallocSum takes a start, max, and end value and produces a pallocSum.
|
|
|
|
|
func packPallocSum(start, max, end uint) pallocSum {
|
|
|
|
|
if max == maxPackedValue {
|
|
|
|
|
return pallocSum(uint64(1 << 63))
|
|
|
|
|
}
|
|
|
|
|
return pallocSum((uint64(start) & (maxPackedValue - 1)) |
|
|
|
|
|
((uint64(max) & (maxPackedValue - 1)) << logMaxPackedValue) |
|
|
|
|
|
((uint64(end) & (maxPackedValue - 1)) << (2 * logMaxPackedValue)))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// start extracts the start value from a packed sum.
|
|
|
|
|
func (p pallocSum) start() uint {
|
|
|
|
|
if uint64(p)&uint64(1<<63) != 0 {
|
|
|
|
|
return maxPackedValue
|
|
|
|
|
}
|
|
|
|
|
return uint(uint64(p) & (maxPackedValue - 1))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// max extracts the max value from a packed sum.
|
|
|
|
|
func (p pallocSum) max() uint {
|
|
|
|
|
if uint64(p)&uint64(1<<63) != 0 {
|
|
|
|
|
return maxPackedValue
|
|
|
|
|
}
|
|
|
|
|
return uint((uint64(p) >> logMaxPackedValue) & (maxPackedValue - 1))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// end extracts the end value from a packed sum.
|
|
|
|
|
func (p pallocSum) end() uint {
|
|
|
|
|
if uint64(p)&uint64(1<<63) != 0 {
|
|
|
|
|
return maxPackedValue
|
|
|
|
|
}
|
|
|
|
|
return uint((uint64(p) >> (2 * logMaxPackedValue)) & (maxPackedValue - 1))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// unpack unpacks all three values from the summary.
|
|
|
|
|
func (p pallocSum) unpack() (uint, uint, uint) {
|
|
|
|
|
if uint64(p)&uint64(1<<63) != 0 {
|
|
|
|
|
return maxPackedValue, maxPackedValue, maxPackedValue
|
|
|
|
|
}
|
|
|
|
|
return uint(uint64(p) & (maxPackedValue - 1)),
|
|
|
|
|
uint((uint64(p) >> logMaxPackedValue) & (maxPackedValue - 1)),
|
|
|
|
|
uint((uint64(p) >> (2 * logMaxPackedValue)) & (maxPackedValue - 1))
|
|
|
|
|
}
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// mergeSummaries merges consecutive summaries which may each represent at
|
|
|
|
|
// most 1 << logMaxPagesPerSum pages each together into one.
|
|
|
|
|
func mergeSummaries(sums []pallocSum, logMaxPagesPerSum uint) pallocSum {
|
|
|
|
|
// Merge the summaries in sums into one.
|
|
|
|
|
//
|
|
|
|
|
// We do this by keeping a running summary representing the merged
|
2023-10-10 12:43:40 +00:00
|
|
|
// summaries of sums[:i] in start, most, and end.
|
|
|
|
|
start, most, end := sums[0].unpack()
|
2019-08-14 16:32:12 +00:00
|
|
|
for i := 1; i < len(sums); i++ {
|
|
|
|
|
// Merge in sums[i].
|
|
|
|
|
si, mi, ei := sums[i].unpack()
|
|
|
|
|
|
|
|
|
|
// Merge in sums[i].start only if the running summary is
|
|
|
|
|
// completely free, otherwise this summary's start
|
|
|
|
|
// plays no role in the combined sum.
|
|
|
|
|
if start == uint(i)<<logMaxPagesPerSum {
|
|
|
|
|
start += si
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Recompute the max value of the running sum by looking
|
|
|
|
|
// across the boundary between the running sum and sums[i]
|
|
|
|
|
// and at the max sums[i], taking the greatest of those two
|
|
|
|
|
// and the max of the running sum.
|
2023-10-10 12:43:40 +00:00
|
|
|
most = max(most, end+si, mi)
|
2019-08-14 16:32:12 +00:00
|
|
|
|
|
|
|
|
// Merge in end by checking if this new summary is totally
|
|
|
|
|
// free. If it is, then we want to extend the running sum's
|
|
|
|
|
// end by the new summary. If not, then we have some alloc'd
|
|
|
|
|
// pages in there and we just want to take the end value in
|
|
|
|
|
// sums[i].
|
|
|
|
|
if ei == 1<<logMaxPagesPerSum {
|
|
|
|
|
end += 1 << logMaxPagesPerSum
|
|
|
|
|
} else {
|
|
|
|
|
end = ei
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-10-10 12:43:40 +00:00
|
|
|
return packPallocSum(start, most, end)
|
2019-08-14 16:32:12 +00:00
|
|
|
}
|