The admission.kv.enabled and admission.sql_kv_response.enabled cluster settings have a default value of false. There will be more cluster settings when we integrate {SQLSQLResponseWork, SQLStatementLeafStartWork, SQLStatementRootStartWork} which will also be false.
This tracking bug is to set the defaults to enabled for 21.2. Work items:

• Investigate drop in cpu utilization when admission control is enabled.
• Integrate for SQL=>SQL response admission
• Store overload only affects write requests to the relevant store (admission: improvements to KV admission #65957)
• Benchmarks (tpccbench etc.) show no slowdown. Results: no slowdown for tpccbench. kv benchmarks that do not overload the store also show no slowdown.
• Multi-store roachtest with single store overloaded.
• Investigate behavior when tpcc is overloaded to figure out interaction between locking and admission control (the graphs show a significant drop in throughput 5+ min into the run, that recovers after 1min)
• Investigate kv0 throughput drop to 0 when store is overloaded (the tokens for the 60s time interval should be non-zero)
• Add trace statements for admission queue wait times (ui,admission: observability improvements for admission control #68595)
• Fixes from tpcc and kv investigation
• Make l0FileCountOverloadThreshold, l0SubLevelCountOverloadThreshold configurable via cluster setting.
• Add admission control metrics to overload page in the DB console (ui,admission: observability improvements for admission control #68595)
• Reduce frequency of goschedstats polling when node is mostly idle (admission control: improve idle CPU usage #66881)
• Roachtest for multi-tenant environments (admission control: support for multi-tenant environments #65954)
• Ensure sane interaction between admission control and rebalancing. Resolved based on internal discussion with KV folks