mirror of
https://github.com/scylladb/scylladb.git
synced 2026-05-01 13:45:53 +00:00
4c3454dd07
Currently said method uses the system semaphore as a catch-all for all scheduling groups it doesn't know about. This is incompatible with the recent forward-porting of the service-level infrastructure as it means that all service level related scheduling groups will fall back to the system scheduling group, which causes two problems: * They will experience much limited concurrency, as the system semaphore is assigned much less count units, to match the much more limited internal traffic. * They compete with internal reads, severely impacting the respective internal processes, potentially causing extreme slowdown, or even deadlock in the case of an internal query executed on behalf of a user query being blocked on the latter. Even if we don't have any custom service level scheduling groups at the moment, it is better to change this such that unknown scheduling groups fall-back to using the user semaphore. We don't expect any new internal scheduling group to pop up any time soon (and if they do we can adjust get_reader_concurrency_semaphore() accordingly), but we do expect user scheduling groups to be created in the future, even dynamically. To minimize the chance of the wrong workload being associated with the user semaphore, all statically created scheduling groups are now explicitly listed in `get_reader_concurrency_semaphore()`, to make their association with the respective semaphore explicit and documented. Added a unit test which also checks the correct association for all these scheduling groups. Fixes: #8508 Tests: unit(dev) Signed-off-by: Botond Dénes <bdenes@scylladb.com> Message-Id: <20210420105156.94002-1-bdenes@scylladb.com>