> On 24 Sep 2024, at 23:23, Mårten Nordheim via Development > <development@qt-project.org> wrote: > > Hello, > > For a while now there has been "Quality of Service" APIs available for > threads and processes in at least Apple[0] and Windows[1]. > Typically you can request either "Eco", and Default (i.e. the OS does its > normal thing) > > The way these work is that they will prefer running the process / thread on a > CPU core that runs slower than the rest or, > with "heterogeneous CPU topology"[2], on a 'Little'[3] (ARM) or 'efficiency' > core (Intel). > Note that the OS is free to run it however it sees fit, it is just a > preference. > > We don't currently have any API to set these preferences. Though the OS API > is quite small, the question is > how do we want to have this API in Qt itself. > > Looking to other frameworks/applications they have gone with an approach > where "Thread Priority" is dropped > in favor of specifying a "Thread Type" / QoS type, that combines both Thread > priority + QoS level. > An example of this is e.g. a "Logging/Telemetry" thread type that would set > BelowNormal priority + request 'Eco' QoS level. > Or a "Rendering" thread type that could use AboveNormal priority + Default > QoS. > Or "AudioProcessing", with High priority + "Eco" QoS (audio processing > usually doesn't handle a lot of data at a, but still > has to complete it quickly, so an 'Eco' core would still be enough.) > > We could do the same thing, but we wouldn't necessarily be able to cover all > angles that our users are interested in, > so we would need to have a way for users to define these. > Adding this would probably also deprecate the thread priority APIs sometime > in the longer-term. > > IMO, it moves the thinking around thread priority from "is my thread high > priority", to > "what does the work this thread is doing need". > > The alternative is a dirt-simple API that just lets users set this variable, > and we leave it to users to > call it as they see fit. > > The API for thread type would be something like this: > > Somewhere.h: > + struct Q{Thread,Application}Type { ... }; // not sure about naming... > > qthread.h: > + void QThread::setThreadType(QThreadType); > + QThreadType QThread::threadType() const; > + static void QThread::setCurrentThreadType(QThreadType) > + static QThreadType QThread::currentThreadType() // maybe > > qcoreapplication.h: > + void QCoreApplication::setApplicationType(QApplicationType); > + QApplicationType QCoreApplication::applicationType() const; > + static void QCoreApplication::setCurrentApplicationType(QApplicationType ) > + static QApplicationType QCoreApplication::currentApplicationType() // maybe > > vs. > > Somewhere.h: > enum class QualityOfService { Eco, Default }; > > qthread.h: > + void QThread::setQualityOfServiceLevel(QualityOfService); // naming tbd > + QualityOfService QThread::qualityOfServiceLevel(); > > qcoreapplication.h: > + void QCoreApplication::setQualityOfServiceLevel(QualityOfService); > + QualityOfService QCoreApplication::qualityOfServiceLevel(); > > > Thanks, > Mårten
Based on my interpretation, I think we can start with a low-level but dirt-simple API that allows applications set a preferred CPU core type (e.g. Eco vs Default) on which a thread might run, together with the existing thread priority. Coupling thread priority and preferred CPU type into a “task type” or “load category” as a convenient, higher-level abstraction can be a follow-up, utilising the former lower-level API. Good naming of those seems hard; I’d stay away from domain specific task type names like “AudioProcessing”. Not sure if it’s useful to have a QCoreApplication API in addition to a QThread API; I’d expect that calling the static QThread setters from main() would be the same as calling the QCoreApplication setter. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development