4

Is there a way to exclude a processor from normal scheduling?

That is, using sched_setaffinity I can indicate which processor a thread should run on, but I'm looking for kind of the inverse. That is, I want exclude a given processor from the normal scheduling, such that only processes which have been explicitly scheduled there can run there.

I also know that during boot I can limit the processors used by the init process, thus all inherited process. I was however hoping there would be a more dynamic solution than this -- something I can change post-boot.

Note that I'm looking to schedule threads, not just high-level processes (this might make a difference in some cases).

edA-qa mort-ora-y
  • 30,295
  • 39
  • 137
  • 267

1 Answers1

5

cgroups, or specifically, the cpuset part of the cgroups infrastructure is the way to do it in Linux. See section 1.4 "exclusive cpusets" in http://www.kernel.org/doc/Documentation/cgroups/cpusets.txt .

Then again, if, as you say in a comment, your system does not have cpusets enabled, you're out of luck.

Also, what you're asking for is perhaps slightly un-orthodox; perhaps if you were to explain what you're actually trying to achieve people would be able to point you to alternative solutions.

janneb
  • 36,249
  • 2
  • 81
  • 97
  • I found cpusets to be working fine on my system. I was just confused by it being a filesystem. – edA-qa mort-ora-y Jul 25 '11 at 13:28
  • 1
    In the most basic case I'm just trying to have a real-time thread reside on one processor and have no other threads/processes execute on that processor. – edA-qa mort-ora-y Jul 25 '11 at 13:29
  • 1
    @edA: The traditional solution to that is to run the real-time thread with SCHED_RR or SCHED_FIFO, ensuring that the realtime thread never is pre-empted by another thread (unless it's another real-time thread with higher priority, of course). – janneb Jul 25 '11 at 13:48
  • That I know. The issue is that we want to preserve the cache on that CPU for only things related to the RT thread -- as the RT thread has a lot of waiting time the CPU is often available for use. This also helps the other threads to prevent them from being punted off and shifted to another system. (And yes, we're concerned with sub-microsecond latencies) – edA-qa mort-ora-y Jul 25 '11 at 14:04
  • Ah, I suspected something like that.. But, how is that going to work anyway, since even with the PREEMPT_RT patch (or some other hard real-time OS) interrupt latency is, IIRC, on the order of tens of microseconds?? – janneb Jul 25 '11 at 14:17
  • The thread may be awoken by another thread, not just hardware interrupts. In these cases we do see much lower latencies, and certainly improvement if nothing shares that core at the time. In some cases even shaving off 100ns processing time would be a benefit to us. – edA-qa mort-ora-y Jul 25 '11 at 14:21