…keys

Add PENDING_CMD_KEYS_PREFETCHED flag to pendingCommand. Set it in
addCommandToBatch() when a command is added to the cross-command
prefetch batch. In mgetCommand, check the flag and fall back to
plain sequential lookups when keys are already warm from the batch.

This eliminates redundant prefetch work that caused regressions
of up to -16% with many I/O threads, while preserving the large
gains (+52-54%) for pipelined workloads where the batch overflows.

The previous guard only skipped intra-command dictPrefetchKeys() when
PENDING_CMD_KEYS_PREFETCHED was set, which requires ALL keys to fit in
the batch. For MGET 100 keys with a batch size of 32, the flag was
never set — both prefetch paths always ran.

On x86 with pipeline-10, this double-prefetching caused -9.6% regression
on mget-100B-100keys-pipeline-10 and -5.6% on setget2000c with 8 IO
threads due to cache-bandwidth contention in ctxPrefetchAndAdvance.

Fix: skip intra-command prefetch when either:
1. PENDING_CMD_KEYS_PREFETCHED is set (all keys fit in batch), OR
2. Pipeline is active (ready_len > 1) — partial batch warmup is
   sufficient, double-prefetching hurts more than it helps.

Single non-pipelined MGET (ready_len <= 1) still uses intra-command
prefetch, preserving the +11% ARM / +25% x86 improvement.

The ready_len > 1 heuristic that skips intra-command dictPrefetchKeys()
assumed cross-command batch prefetching always runs during pipelining.
When prefetch-batch-max-size is 0 (batch disabled), addCommandToBatch()
returns C_ERR immediately and no keys are warmed, but ready_len > 1
still holds for any pipeline — causing MGET to skip its only prefetch
opportunity.

Add server.prefetch_batch_max_size > 0 to the ready_len guard so
intra-command prefetch runs when the batch system is disabled.

The prefetchGetObjectValuePtr callback adds one state-machine iteration
per key to prefetch the first cache line of the value allocation.
For EMBSTR values (<=44B) it returns NULL (value is embedded in the kv
object), making the iteration pure overhead.  For large RAW values
(>=1KiB) it warms <10% of the data while adding measurable cost —
profiling shows 3B samples in ctxPrefetchValdata vs 17.8B total in the
prefetch path.

Pass NULL instead: skip value-data prefetch entirely in the MGET
intra-command path.  The dict bucket/entry/kv-object prefetch provides
the bulk of the improvement; addReplyBulk handles value data access
sequentially.

Three optimizations to the dict prefetch state machine:

1. Replace modulo with branch in ctxPrefetchAndAdvance — avoids
   expensive division on every state transition.

2. Add remaining counter to DictPrefetchCtx — ctxNextInfo returns
   NULL immediately when all keys are done instead of scanning the
   full array. Eliminates O(n) scan per call as keys complete.

3. Fast-path in ctxPrefetchKvobj when no value-data callback and
   entry is a direct key — do key comparison inline and skip the
   VALDATA state entirely, saving one round-trip through the state
   machine per key.

For batches of <=10 keys, replace the full dictPrefetchKeys state
machine with a simple loop that prefetches hash table buckets only.

The state machine has ~4 states per key with function dispatch and
round-robin scanning overhead.  Profiling shows this costs 4.3% of
total CPU for 10-key MGET with 1KiB values — matching the observed
regression exactly.  A single-pass bucket prefetch eliminates the
iteration overhead while still warming the hash chain heads.

Larger batches (>10 keys) continue using the full state machine where
the multi-round interleaving provides net benefit.

Adds intra-command batched prefetch to msetGenericCommand. When
processing multiple keys, dict bucket pointers for the next batch of 16
keys are prefetched into L1 cache before executing setKey for each key.
This hides memory latency from scattered dict lookups in large MSET
commands.

The prefetch is advisory — correctness does not depend on it. If a
rehash occurs mid-batch (triggered by a prior setKey expanding the dict),
the prefetched bucket may be stale. The subsequent lookupKeyWriteWithLink
inside setKey re-derives the correct bucket.

Both the MSETNX existence-check pass and the write pass are batched.
Single-key MSET or empty-dict cases skip prefetch entirely.

Addresses three review threads on PR redis#15043:

1. Stale dict pointer (augmentcode + cursor bugbot, high/medium).
   In cluster mode, server.db[].keys is created with KVSTORE_FREE_EMPTY_DICTS.
   A prior batch's setKey -> expireIfNeeded may delete the last pre-existing
   key in the slot, triggering freeDictIfNeeded; the subsequent dbAddByLink
   then allocates a new dict. The cached dict* from before the batch would be
   a dangling pointer on the next msetPrefetchBatch call. Re-fetch the slot
   dict inside a new msetMaybePrefetchBatch helper that runs per batch.

2. Helper signature (sundb). Change msetPrefetchBatch to take `robj **argv`
   instead of `client *c`, making the contract explicit.

3. Duplication (sundb). Collapse the `if (use_prefetch) { batched } else
   { simple }` branches in both the MSETNX existence-check pass and the
   write pass into a single batched loop that conditionally calls the
   prefetch helper. `use_prefetch` now only gates the prefetch call, not
   the loop structure.

Add regression tests in tests/unit/type/string.tcl:
- MSET spanning multiple prefetch batches (16, 17, 32, 33, 40 keys)
- MSET overwriting expired keys across a batch boundary (exercises the
  expireIfNeeded path in the same code that would UAF under cluster mode)

…mework

… callback

Two review comments from Cursor Bugbot on dcb8aa8:

1. Missing `#undef MGET_LIGHT_PREFETCH_MAX` at the end of mgetCommand.
   MGET_BATCH was already undef'd but its sibling was not.

2. The `dictPrefetchKeys()` docstring example passed
   `prefetchGetObjectValuePtr` as the value-data callback, while the
   mgetCommand caller passes NULL on purpose (the callback's extra state
   machine work costs more than warming the value payload saves, since the
   following lookupKeyRead + addReplyBulk touch the payload immediately and
   the hardware prefetcher is already on it). Update the example to show
   the typical NULL form and document when passing a non-NULL callback
   would actually be worthwhile.

Decouple the prefetch state machine from kvobject. The state machine
previously knew about kvobj fields (current_kv, kvobjGetKey) and the
default value-data callback (prefetchGetObjectValuePtr) lived inside
memory_prefetch.c. That coupled a generic dict facility to one
specific dict's stored-key layout.

Two new optional callbacks on dictType:

  void *prefetchEntryKey(const dictEntry *de);
  void *prefetchEntryValue(const dictEntry *de);

The state machine renames the post-entry states to match:

  PREFETCH_KVOBJ   -> PREFETCH_ENTRY_KEY
  PREFETCH_VALDATA -> PREFETCH_ENTRY_VALUE

PREFETCH_ENTRY_KEY asks the dictType to bring the entry's key payload
into cache (returns the address to prefetch, or NULL if the entry
already carries everything keyCompare needs). PREFETCH_ENTRY_VALUE
runs the keyCompare and on a hit asks the dictType to prefetch the
value-side payload.

dbDictType registers both callbacks in server.c:

  - prefetchEntryKey returns dictGetKey(de) only when the kvobj is
    out-of-line (matches today's dictEntryIsKey check).
  - prefetchEntryValue returns kv->ptr for OBJ_STRING/RAW (the old
    prefetchGetObjectValuePtr behaviour, now where it belongs).
  - dbExpiresDictType only sets prefetchEntryKey (no values).

The PrefetchGetValueDataFunc typedef and the trailing get_val_data
parameter are removed from the dictPrefetchKeys() public API and from
the cross-command dictPrefetch() wrapper - the dict's own type now
drives this end-to-end. mgetCommand's call site updates accordingly.