title: How to prioritize (or set scheduling policy for) the 'manager' and 'worker' threads of a process?
body: <p>I'm running a process (on a Linux 3.x-based OS) in which:</p>
  
  <ul>
  <li>A few threads are 'manager' threads (for simplicity assume they make decisions regarding which worker threads should do what, but do not do any I/O and the amount of CPU time they need, altogether, is shorter/much shorter than the worker threads')</li>
  <li>More threads are 'worker' threads: They do heavy lifting computation-wise, and I have no problem with their being preempted at any time.</li>
  </ul>
  
  <p>It's possible that there's oversubscription (i.e. more workers threads than twice the cores on an Intel processor with HT). Now, what I'm seeing is that the 'manager' threads don't get processor time frequently enough. They're not entirely 'starved', I just want to give them a boost. So, naturally I thought about setting different thread prioritization (I'm on Linux) - but then I noticed the different choices for thread schedulers and their effect. At this point I got confused, or rather - it's not clear to me:</p>
  
  <ul>
  <li>Which scheduling policy should I choose for the managers, and which for the workers?</li>
  <li>What should I set the thread priorities to (if at all)?</li>
  <li>Do I need to have my threads yield() occasionally?</li>
  </ul>
  
  <p><strong>Notes:</strong></p>
  
  <ul>
  <li>I'm intentionally not saying anything about the language or thread pool mechanism. I want to ask this question in the more general setting.</li>
  <li>Please do not make assumptions about CPU cores. There may be many of them, or maybe just one, and perhaps I need workers (or workers and managers) on each core.</li>
  <li>The worker threads may or may not do I/O. Answers for the case of them not doing any I/O are welcome, though.</li>
  <li>I don't really need the system to be very responsive other than running my application. I mean, I'd rather be able to SSH in there and have my typing echoed to me without a significant delay, but no real restrictions there.</li>
  </ul>