)]}'
{
  "commit": "e1b5f347e78c733bb0743df04c990e20f74bf188",
  "tree": "21f01ca7b096f632d97c7608f3aa470aff07521e",
  "parents": [
    "226346bb763233ed9341bc1d829752628479845f"
  ],
  "author": {
    "name": "Michael Anthony Knyszek",
    "email": "mknyszek@google.com",
    "time": "Wed Mar 16 15:47:57 2022 +0000"
  },
  "committer": {
    "name": "Michael Knyszek",
    "email": "mknyszek@google.com",
    "time": "Tue Apr 26 22:08:42 2022 +0000"
  },
  "message": "runtime: reduce max idle mark workers during periodic GC cycles\n\nThis change reduces the maximum number of idle mark workers during\nperiodic (currently every 2 minutes) GC cycles to 1.\n\nIdle mark workers soak up all available and unused Ps, up to GOMAXPROCS.\nWhile this provides some throughput and latency benefit in general, it\ncan cause what appear to be massive CPU utilization spikes in otherwise\nidle applications. This is mostly an issue for *very* idle applications,\nones idle enough to trigger periodic GC cycles. This spike also tends to\ninteract poorly with auto-scaling systems, as the system might assume\nthe load average is very low and suddenly see a massive burst in\nactivity.\n\nThe result of this change is not to bring down this 100% (of GOMAXPROCS)\nCPU utilization spike to 0%, but rather\n\n  min(25% + 1/GOMAXPROCS*100%, 100%)\n\nIdle mark workers also do incur a small latency penalty as they must be\ndescheduled for other work that might pop up. Luckily the runtime is\npretty good about getting idle mark workers off of Ps, so in general\nthe latency benefit from shorter GC cycles outweighs this cost. But, the\ncost is still non-zero and may be more significant in idle applications\nthat aren\u0027t invoking assists and write barriers quite as often.\n\nWe can\u0027t completely eliminate idle mark workers because they\u0027re\ncurrently necessary for GC progress in some circumstances. Namely,\nthey\u0027re critical for progress when all we have is fractional workers. If\na fractional worker meets its quota, and all user goroutines are blocked\ndirectly or indirectly on a GC cycle (via runtime.GOMAXPROCS, or\nruntime.GC), the program may deadlock without GC workers, since the\nfractional worker will go to sleep with nothing to wake it.\n\nFixes #37116.\nFor #44163.\n\nChange-Id: Ib74793bb6b88d1765c52d445831310b0d11ef423\nReviewed-on: https://go-review.googlesource.com/c/go/+/393394\nReviewed-by: Michael Pratt \u003cmpratt@google.com\u003e\nRun-TryBot: Michael Knyszek \u003cmknyszek@google.com\u003e\nTryBot-Result: Gopher Robot \u003cgobot@golang.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0a00801a1144484e1622dcbf32e0b681cd0e6452",
      "old_mode": 33188,
      "old_path": "src/runtime/export_test.go",
      "new_id": "0cf2fb4ea7c16985a9a47ca952aa38bbb5b7d728",
      "new_mode": 33188,
      "new_path": "src/runtime/export_test.go"
    },
    {
      "type": "modify",
      "old_id": "9f17e474889a303a5d98cead2ebe560d3759b180",
      "old_mode": 33188,
      "old_path": "src/runtime/mgc.go",
      "new_id": "604d0db24a2492e3ba6c6f929aad59d66ff3681e",
      "new_mode": 33188,
      "new_path": "src/runtime/mgc.go"
    },
    {
      "type": "modify",
      "old_id": "940bc526b48fb78179277b6a0bd931181ce363ea",
      "old_mode": 33188,
      "old_path": "src/runtime/mgcpacer.go",
      "new_id": "562520e14e6737ceeb2e3914b460b019234aade7",
      "new_mode": 33188,
      "new_path": "src/runtime/mgcpacer.go"
    },
    {
      "type": "modify",
      "old_id": "b49e3a8d24752b3e32f0a72eee9d6ad65e8b063c",
      "old_mode": 33188,
      "old_path": "src/runtime/mgcpacer_test.go",
      "new_id": "23628898d481b72758ffe7040005fbc464fb07d9",
      "new_mode": 33188,
      "new_path": "src/runtime/mgcpacer_test.go"
    },
    {
      "type": "modify",
      "old_id": "96d44efdddf30f73cf9d68b85a21f713d90db8e5",
      "old_mode": 33188,
      "old_path": "src/runtime/proc.go",
      "new_id": "4aeb66c92d4212a471807cbf6d2c36df3caa9d9a",
      "new_mode": 33188,
      "new_path": "src/runtime/proc.go"
    }
  ]
}