package cgroup
Import Path
internal/runtime/cgroup (on go.dev)
Dependency Relation
imports 4 packages, and imported by 2 packages
Package-Level Type Names (total 2)
Package-Level Functions (total 5)
FindCPU finds the path to the CPU cgroup that this process is a member of
and places it in out. scratch is a scratch buffer for internal use.
out must have length PathSize. scratch must have length ParseSize.
Returns the number of bytes written to out and the cgroup version (1 or 2).
Returns ErrNoCgroup if the process is not in a CPU cgroup.
FindCPUCgroup finds the path to the CPU cgroup that this process is a member of
and places it in out. scratch is a scratch buffer for internal use.
out must have length PathSize. scratch must have length ParseSize.
Returns the number of bytes written to out and the cgroup version (1 or 2).
Returns ErrNoCgroup if the process is not in a CPU cgroup.
FindCPUMountPoint finds the mount point containing the specified cgroup and
version with cpu controller, and compose the full path to the cgroup in out.
scratch is a scratch buffer for internal use.
out must have length PathSize, may overlap with cgroup.
scratch must have length ParseSize.
Returns the number of bytes written to out.
Returns ErrNoCgroup if no matching mount point is found.
OpenCPU returns a CPU for the CPU cgroup containing the current process, or
ErrNoCgroup if the process is not in a CPU cgroup.
scratch must have length ScratchSize.
Returns average CPU throughput limit from the cgroup, or ok false if there
is no limit.
Package-Level Variables (only one)
var ErrNoCgroup error
Package-Level Constants (total 6)
Required space to parse /proc/self/mountinfo and /proc/self/cgroup.
See findCPUMount and findCPURelativePath.
Required space to store a path of the cgroup in the filesystem.
Required amount of scratch space for CPULimit.
TODO(prattmic): This is shockingly large (~70KiB) due to the (very
unlikely) combination of extremely long paths consisting mostly
escaped characters. The scratch buffer ends up in .bss in package
runtime, so it doesn't contribute to binary size and generally won't
be faulted in, but it would still be nice to shrink this. A more
complex parser that did not need to keep entire lines in memory
could get away with much less. Alternatively, we could do a one-off
mmap allocation for this buffer, which is only mapped larger if we
actually need the extra space.
const VersionUnknown Version = 0![]() |
The pages are generated with Golds v0.8.3-preview. (GOOS=linux GOARCH=amd64) Golds is a Go 101 project developed by Tapir Liu. PR and bug reports are welcome and can be submitted to the issue list. Please follow @zigo_101 (reachable from the left QR code) to get the latest news of Golds. |