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.
FindCPUMountPoint finds the root of the CPU cgroup mount 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.
Returns ErrNoCgroup if the process is not in a CPU cgroup.
FindCPURelativePath finds the path to the CPU cgroup that this process is a member of
relative to the root of the cgroup mount and places it in out. scratch is a
scratch buffer for internal use.
out must have length PathSize minus the size of the cgroup mount root (if
known). 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.
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.7.7-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. |