fix(profiling): swap on-CPU greenlet to position 0 in unwind_greenlets

[taegyunkim]

Description

Fixes a ~1.6× over-count of total CPU time reported by the stack v2 sampler
for gevent workloads.

ThreadInfo::sample calls render_thread_begin (creates sample S0), then
render_cpu_time (pushes the CPU delta on S0), then renders one greenlet
per current_greenlets entry via render_task_begin.

render_task_begin reuses the existing sample for the first task it sees and
starts a new sample for subsequent tasks. The new-sample path re-pushes
thread_state.cpu_time_ns whenever on_cpu=true. For asyncio this is
harmless because unwind_tasks already swaps the on-CPU task to
leaf_tasks[0], so the duplicate push never fires.

unwind_greenlets had no such swap: current_greenlets ended up in
std::unordered_map iteration order, so when the on-CPU greenlet landed at
position ≥ 1, its CPU delta was attributed twice. For M=4 workers, the
over-count converges to ~1.5-1.6× of the real CPU consumed by the process.

This change mirrors the existing unwind_tasks swap at the end of
unwind_greenlets. std::swap on std::unique_ptr<StackInfo> is a noexcept
pointer swap. on_cpu is set from snap.frame == Py_None, true only for the
currently-running greenlet, so multiple-on-CPU is impossible by construction.

Out of scope here: the deeper TODO in render_cpu_time ("thread-level CPU
time is task time") that would normalize at the task level. That's the
architectural fix the findings doc recommends; this PR is the minimal
symptom-fix.

Refs: DataDog/experimental#10595 (Phase 1 findings, Finding 3), PROF-14213.

Testing

Added tests/profiling/collector/test_stack.py::test_gevent_cpu_time_total_accuracy:

• 4 staggered worker greenlets, each cycling ~10ms of pure-Python CPU burn
  (busy-loop on `time.process_time_ns()`) followed by `gevent.sleep(50ms)`
  for 3 seconds.
• Ground truth: `time.process_time_ns()` delta over the timed region.
• Profile read: sum `cpu-time` across all samples in the resulting pprof.
• Assert: `0.85 ≤ profile_cpu / actual_cpu ≤ 1.20`.

Verified locally on Python 3.13 + gevent latest via
`scripts/run-tests --venv 177daf3`:

• Without this fix (rebuilt main): `ratio=1.60` → test fails (upper bound
  rejects the 1.6× bug).
• With this fix: ratio ≈ 1.0 → test passes alongside the rest of the
  profiling suite (350 tests).

A test-only companion PR demonstrates the failure on `main`: #18221.

Risks

• C++ change is 7 lines, lives at the end of `unwind_greenlets`, and exactly
  mirrors the existing pattern in `unwind_tasks`. No header changes, no API
  changes.
• User-visible CPU totals for gevent workloads will decrease (closer to
  actual). Release note added under `fixes:`.
• Lower bound (0.85×) in the new test guards against a regression where the
  fix accidentally drops real CPU samples (e.g. reintroducing the
  `is_running()` gate removed in fix(profiling): always report CPU time regardless of Thread running state #16273).

Additional Notes

PLAN.md

```markdown
$(cat PLAN.md)
```

PROMPTS.md

```markdown
$(cat PROMPTS.md)
```

[cit-pr-commenter-54b7da]

Codeowners resolved as

ddtrace/internal/datadog/profiling/stack/src/echion/threads.cc          @DataDog/profiling-python
releasenotes/notes/profiling-fix-gevent-cpu-overcount-1d2aa67778642a97.yaml  @DataDog/apm-python
tests/profiling/collector/test_stack.py                                 @DataDog/profiling-python

[datadog-prod-us1-6]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 8 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-py | build linux serverless: [arm64, cp315-cp315, v113741357-d2b8243-manylinux2014_aarch64, 1]     

🔄 Retry job. This looks flaky and may succeed on retry.

Failed to create pod sandbox: unable to allocate IP via local cilium agent due to no available IPs on the node.

DataDog/apm-reliability/dd-trace-py | build linux serverless: [amd64, cp315-cp315, v113741238-d2b8243-manylinux2014_x86_64, 1]     

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.

NotImplementedError: This version of CPython is not supported yet during ddtrace import

DataDog/apm-reliability/dd-trace-py | build linux serverless: [arm64, cp315-cp315, v113741589-d2b8243-musllinux_1_2_aarch64, 1]     

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.

Unable to access repository due to Service Unavailable error (HTTP 503) from gitretriever.

View all 8 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 323e127 | Docs | Datadog PR Page | Give us feedback!}

[KowalskiThomas]

Might be worth adding something or changing something in prof correctness following these changes!

[taegyunkim]

Might be worth adding something or changing something in prof correctness following these changes!

@KowalskiThomas yup, that's the plan

[taegyunkim]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-22 15:29:44 UTC ℹ️ Start processing command /merge

---

2026-05-22 15:29:53 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

---

2026-05-22 19:00:15 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in main is approximately 54m (p90).

---

2026-05-22 19:35:16 UTC ℹ️ MergeQueue: This merge request was merged