chore(deps): bump cudarc from 0.12.1 to 0.19.4#80
Merged
Conversation
dependabot
Bot
added
dependencies
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
2 similar comments
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Contributor
Author
|
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting |
Bumps [cudarc](https://github.com/chelsea0x3b/cudarc) from 0.12.1 to 0.19.4. - [Release notes](https://github.com/chelsea0x3b/cudarc/releases) - [Commits](chelsea0x3b/cudarc@v0.12.1...v0.19.4) --- updated-dependencies: - dependency-name: cudarc dependency-version: 0.19.4 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/cargo/cudarc-0.19.4
branch
from
April 22, 2026 12:54
bf730bf to
ac1203c
Compare
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
TinDang97
added a commit
that referenced
this pull request
Jul 16, 2026
…task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com>
TinDang97
added a commit
that referenced
this pull request
Jul 16, 2026
…task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com>
pilotspacex-byte
added a commit
that referenced
this pull request
Jul 16, 2026
…edger, stub-only recovery, replay demote (task #56) (#349) * fix(storage): make used_memory truthful under disk-offload restarts (task #56) The G2 acceptance run (4 shards, --maxmemory 256MB, 2.6GB dataset, disk-offload enabled) reported INFO used_memory at 406-762MB against the 256MB cap, and worse after a kill-9 restart. A 2-shard/8MB-cap/40k-key macOS repro (tests/used_memory_offload_truthful.rs) instrumented at load, steady state, and post-restart isolated three independent bugs: 1. used_memory was literally process RSS (src/command/connection.rs), not the logical ledger --maxmemory eviction actually gates on. RSS carries allocator overhead, mmap'd cold-read page-cache, the Lua script cache, and the replication backlog -- none of which eviction charges against the cap. INFO now reports the same KV(+ColdIndex)+vector+text+graph used-term ShardDatabases::recompute_elastic_budget already gates on (admin::metrics_setup::logical_used_memory_bytes); used_memory_rss / used_memory_peak still expose the true OS footprint, a new moon_used_memory_bytes Prometheus gauge mirrors the ledger, and MEMORY DOCTOR gained a "gated vs RSS vs outside-the-cap" section. 2. Restart double-loaded every spilled String key into hot RAM (src/persistence/recovery.rs): v3 recovery Phase 3 re-inserted each previously-spilled String entry directly into the hot DashTable (#79-04, predating cold read-through) AND rebuilt a ColdIndex stub for the same key (#80-02) -- nobody removed the first loop when the second, correct mechanism landed. Every value type now recovers as a cold-index-only stub; the first GET lazily promotes and only then charges used_memory, via the same path ordinary cold read-through uses. 3. AOF replay re-hydrated already-cold keys back into hot RAM on every restart (src/main.rs, src/storage/db.rs): fixing #2 exposed this second, independent path -- only surfaces with --appendonly yes AND disk-offload both active. An evicted-and-spilled key gets no AOF DEL record (record_reason_del never fires for a spilled entry), so AOF replay blindly reapplies the key's original SET into hot RAM with zero cold-tier awareness, transiently re-inflating used_memory to ~6x steady state after every restart (self-healing over several eviction ticks, slower the larger the offloaded dataset -- the "got WORSE after restart" symptom). Database::demote_replayed_cold_shadows reconciles this right after AOF replay finishes, before the server accepts connections: any key still present in the (already crash-consistent) ColdIndex at that point is provably redundant with what replay just wrote hot for it, so the redundant hot copy is dropped. Red/green: tests/used_memory_offload_truthful.rs drives all three mechanisms end-to-end (spill past maxmemory, confirm real disk spill, SIGKILL, restart) and asserts used_memory stays within 1.75x maxmemory at steady state AND immediately post-restart. Before (pre-fix baseline binary): steady_max_used=39,632,896 (4.7x the 8MB cap; used == rss, confirming the RSS-as-used_memory bug) -- test fails at the steady-state assertion. After (all three fixes): steady_max_used=8,388,410 (~1.0x cap), post_restart_max_used=8,388,410 (identical to steady state, no post-restart transient at all) -- test passes both assertions, reproducibly across repeated runs. Scope: confined to accounting/reporting (charging, uncharging, INFO/ metrics surfaces, restart re-charge paths) per the task boundary -- spill file format/batching is owned by a separate concurrent effort and was not touched. Gates run on macOS (VM occupied by a concurrent crash-matrix run): - cargo fmt --check: clean - cargo clippy --tests -- -D warnings (default features): clean - cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings: clean - cargo test --lib (default features): 4331 passed, 0 failed, 1 ignored - cargo test --lib --no-default-features --features runtime-tokio,jemalloc storage::db::: 35 passed - cargo test --release --test used_memory_offload_truthful -- --ignored: pass (repeated) - cargo test --release --test crash_matrix_per_shard_aof: 3 passed - cargo test --release --test crash_recovery_cold_del_resurrection: 2 passed - cargo test --release --test crash_recovery_disk_offload_no_aof: 1 passed - cargo test --release --test crash_recovery_orphan_sweep_readiness: 1 passed - cargo test --release --test memory_doctor_response: 1 passed - cargo test --test aof_multidb_kill9: 4 passed VM-scale validation still needed: re-run the original G2 acceptance scenario (4 shards, 2.6GB dataset, --maxmemory 256MB) on moon-dev once free, to confirm used_memory stays truthful at that scale and that the post-restart AOF-replay-demotion pass completes promptly on a much larger cold index / AOF incr log than this repro's 40k keys. author: Tin Dang <tindang.ht97@gmail.com> * fix(storage): close three adversarial-review DO-NOT-SHIP gaps on used_memory offload fix Adversarial review of fix/t56-used-memory-offload flagged three gaps before this branch could ship: a critical stale-data resurrection bug, a recovery path where the new demotion logic was never invoked, and an undocumented used_memory parity gap. All three are fixed here. - CRITICAL: Database::set() (src/storage/db.rs) now clears a key's ColdIndex shadow the instant a second write to that key is observed (InsertOrUpdate::Updated). Without this, a key spilled at v1 and then live-overwritten to v2 (no re-eviction before a crash) would have its hot v2 wrongly dropped by demote_replayed_cold_shadows on restart, resurrecting stale v1. Provably safe because AOF replay always starts from an empty DashTable, so a key's first replayed write is always Inserted (left alone) and any later write during that replay can only be Updated if the AOF recorded a write after the one that got spilled. - HIGH: recover_shard_v3_pitr's Phase 4b appendonly.aof fallback (src/persistence/recovery.rs) is the ONLY KV replay path under runtime-tokio + --shards 1 (no AofManifest exists there), and it never called demote_replayed_cold_shadows. It now does, closing the gap for that runtime/shard combination. - MEDIUM: logical_used_memory_bytes() (src/admin/metrics_setup.rs) and the moon_used_memory_bytes gauge now include the Lua script cache and replication backlog, matching real Redis's used_memory semantics (allocator-attributed, not eviction-reclaimable). Both terms were already tracked as separate moon_memory_bytes{kind=...} gauges, so this costs no new instrumentation. The actual --maxmemory eviction gate (ShardDatabases::recompute_elastic_budget) is unchanged and narrower. MEMORY DOCTOR (src/command/server_admin.rs) and docs/guides/monitoring.md now show three distinct figures: elastic budget, used_memory (reported), and RSS. New tests (all RED before their respective fix, GREEN after): - storage::db::tests::test_second_write_invalidates_cold_shadow (unit) - tests/cold_shadow_overwrite_resurrection.rs (overwritten_cold_key_returns_new_value_after_crash) - tests/cold_shadow_single_shard_tokio.rs (single_shard_overwritten_cold_key_returns_new_value_after_crash, run against a runtime-tokio+jemalloc binary; uses SETEX per the monoio-write-gate/inline-SET dispatch gotcha) Verified: cargo fmt --check, cargo clippy --tests -- -D warnings (default features), cargo clippy --no-default-features --features runtime-tokio,jemalloc --tests -- -D warnings, cargo test --lib (4332 passed), plus the full existing disk-offload/crash-recovery integration suite (used_memory_offload_truthful, crash_recovery_cold_del_resurrection, crash_matrix_per_shard_aof, memory_doctor_response, aof_multidb_kill9) — all green with no regressions. author: Tin Dang --------- Co-authored-by: Tin Dang <tindang.ht97@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps cudarc from 0.12.1 to 0.19.4.
Release notes
Sourced from cudarc's releases.
... (truncated)
Commits
780e783v0.19.49eb8c67Merge pull request #552 from chelsea0x3b/parallize-bindings8877130Merge pull request #551 from chelsea0x3b/cuda-13.2768a19cMerge pull request #553 from LateinCecer/expose-has-async-allocaae1a76Fixes for cuda 13.2acf393aParallelizing bindings generatored427d1Generating bindings from linux3bddb5dAdded CudaContext::has_async_alloc getter method788ebe7Merge pull request #546 from TannerRogalsky/cuda-130208360eb9Merge pull request #550 from chelsea0x3b/unblock-cuCtxCreate_v4