Motivation

The existing memory_prefetch.c framework amortizes dictionary lookup cache misses across commands in I/O-thread batches, but provides no mechanism for a single multi-key command to prefetch its own keys. When a command like MGET key1 ... key100 executes, each lookupKeyRead() triggers a chain of cache misses (hash bucket → entry → kvobj → value data). With 5M+ keys, nearly every access is an L3/DRAM miss. For MGET 100 keys this means ~400 sequential cache misses with the CPU stalling on each one.

This PR refactors the prefetch state machine to be reusable and applies it inside mgetCommand as the first consumer.

Changes

1. New DictPrefetchCtx abstraction (memory_prefetch.c)

Extracted a lightweight context struct from the global PrefetchCommandsBatch. All state machine functions (prefetchBucket, prefetchEntry, prefetchKVObject, prefetchValueData) were refactored to operate on a DictPrefetchCtx * parameter instead of accessing the global batch directly. The existing cross-command I/O-thread path creates a DictPrefetchCtx from the global batch fields — behavior is fully backward-compatible.

2. New public API (memory_prefetch.h)

void dictPrefetchKeys(struct dict **dicts, void **keys, size_t nkeys,
                      PrefetchGetValueDataFunc get_val_data);
void *prefetchGetObjectValuePtr(const void *val);

dictPrefetchKeys() stack-allocates KeyPrefetchInfo[nkeys] and runs the same 5-state round-robin machine (BUCKET → ENTRY → KVOBJ → VALDATA → DONE). Zero heap allocations in the hot path.

3. Cross-command awareness (memory_prefetch.c + server.h)

Added PENDING_CMD_KEYS_PREFETCHED flag to pendingCommand. When addCommandToBatch() successfully adds all keys of a command to the cross-command batch, it sets this flag. mgetCommand checks the flag and skips intra-command prefetching when keys are already warm — avoiding redundant work when I/O threads have already prefetched everything.

4. Optimized mgetCommand (t_string.c)

Processes keys in batches of 16 with three fast paths:

• Single key: direct lookup, zero overhead
• Empty dict: NULL-reply loop with lookupKeyRead() for side effects
• Cross-command prefetched: simple loop when I/O threads already warmed the cache

Benchmark results

Tested on r8i.4xlarge ubuntu24.04 with redis-benchmarks-specification memtier suites. best of 3 iterations.

Single-threaded (no I/O threads)

Single-threaded: +3% to +50% across all tests, zero regressions.

4 I/O threads

4 I/O threads: up to +68% on pipelined workloads. Regressions on non-pipelined high-key-count tests (20, 100 keys) possibly due to partial overlap with cross-command prefetching.

16 I/O threads

16 I/O threads: up to +56% on pipelined workloads. Same regression pattern as 4 I/O threads on non-pipelined high-key-count tests.