On the linux platform, CPU scheduler(EAS) track all the threads to decide its task utilization and CPU frequency.
Assuming we have a SW thread pool module, it creates fixed amount threads and re-uses all the threads when user posts jobs to it. The pool has a capability which is to fetch the jobs continuously to run without explicitly going to sleep. In another word, the thread finishes one job and then directly fetch another job in the pool to run without going to sleep itself.
My questions are:
(1) what is the difference between explicitly going to sleep and directly fetching another job in th aspect of Linus CPU scheduler?
(2) In my opinion, each thread’s util grows during its running time and decay when going to sleep. It keeps stable util and frequency when the thread runs similar jobs. But when it comes to the thread inside thread pool, the jobs become different for each running time. Therefore, the util might become un-stable which is bad for scheduler to predict its frequency. Do I misunderstand anything?
(3) For the capability that directly fetching new jobs without sleeping, it might cause high util/frequency when the thread runs several jobs continuously. Then after it goes to sleep, the thread might starts from a relatively high util. In this case,the next new job in the same thread might own larger CPU frequencies. Am I still right?
(4) For the thread pool mechanism, is it essentially incapable for CPU scheduler to predict its frequency? What’s your opinion?
(5)In your opinion, what’s the pros and cons for the thread pool mechanism?
Thanks!
I turn on the capability of thread pool. I try to dump the utils of the job inside thread pool. The util of the thread is more than my expectations. Therefore, this is why I ask here.