> 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

Reply via email to