Deprioritize long-running tasks (such as joining rooms or resolving federation-transaction outliers) #195

Open
opened 2021-11-25 13:52:22 +00:00 by shadowjonathan · 2 comments
shadowjonathan commented 2021-11-25 13:52:22 +00:00 (Migrated from gitlab.com)

This can be done both with tokio::block_in_place and thread-priority, a simple wrapper which takes FnOnce that invokes the former, and the latter, and restores thread priority on exit, would make conduit snappier even if a thread is resolving/fetching state for a room.

Additionally, block_in_place signals to the executor that the current operation is blocking, so the executor will make sure at least some threads of async compute are ready to be worked with, this makes sure conduit doesn't freeze up on low-core-count machines.

Joining this behaviour with thread-priority could make room joins non-detrimental to the server's resource usage, as it will balance out.

This can be done both with `tokio::block_in_place` and `thread-priority`, a simple wrapper which takes `FnOnce` that invokes the former, and the latter, and restores thread priority on exit, would make conduit snappier even if a thread is resolving/fetching state for a room. Additionally, `block_in_place` signals to the executor that the current operation is blocking, so the executor will make sure at least some threads of async compute are ready to be worked with, this makes sure conduit doesn't freeze up on low-core-count machines. Joining this behaviour with `thread-priority` could make room joins non-detrimental to the server's resource usage, as it will balance out.
timokoesters commented 2021-12-14 13:43:27 +00:00 (Migrated from gitlab.com)

I think this is very difficult to think about. Sometimes joining rooms needs to have more priority than loading room history, sometimes the other way around. I think it's okay to trust tokio to do fair scheduling.

I think this is very difficult to think about. Sometimes joining rooms needs to have more priority than loading room history, sometimes the other way around. I think it's okay to trust tokio to do fair scheduling.
shadowjonathan commented 2021-12-14 14:13:30 +00:00 (Migrated from gitlab.com)

I think at the very least, block_in_place should be used for potentially long-running synchronous tasks, this makes tokio able to keep scheduling and running asynchronous tasks, and make sure the executor isn't starved of threads it can run off of.

I think at the very least, `block_in_place` should be used for potentially long-running synchronous tasks, this makes tokio able to keep scheduling and running asynchronous tasks, and make sure the executor isn't starved of threads it can run off of.
Sign in to join this conversation.
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Matthias/conduit#195
No description provided.