Scheduler and interrupts tweaks benchmarks

[solca]

Hi!

I recently learn about the following Linux scheduler policies:

SCHED_NORMAL
SCHED_FIFO
SCHED_RR

My attention got stuck with FIFO and RR which make the process run until it sleeps or yields, something very nice for raw performance specially with lots of cores.

Having a quad Q6600 G0 I run ET:QW (threading enabled) with FIFO or RR with improved perceived interactivy, also I run irqbalance daemon in one shot mode for initial interrupt balancing.

I have been wondering what options are the best for performance and efficiency so I ask phoronix to include this tests in their benchmarks.

What should answer our questions about the usefullness of tweaking to this level is that phoronix conduct benchmarking the different SCHED_ policies and if irqbalance is of any help or if manual IRQ affinity is required for better performance that would help a lot to know if advanced tweaking is of any help.

Obviously all this is of value just to SMP setups but maybe not.

I run my tweaks for ET:QW like this:

schedtool -F -p 50 `pidof etqw-rthread.x86`
echo 8 >/proc/irq/2/smp_affinity (kbd)
echo 8 >/proc/irq/12/smp_affinity (mouse)
echo 8 >/proc/irq/21/smp_affinity (nvidia)

[Vadi]

I have a 1.5ghz cpu and an nvidia geforce 8600gt, 512mb - do you think your tweaks would have any effect on my system?

(I just don't know how to measure the performance, heh. It's fine except for very very close combat with lots of objects moving about, then it gets a bit laggy and TK's happen)

[solca]

Originally Posted by Vadi

I have a 1.5ghz cpu and an nvidia geforce 8600gt, 512mb - do you think your tweaks would have any effect on my system?

I don't think it will have any effect as your system is UP (uni-processor), the thing is that is hard for us just simple users benchmark our favorites games, that's why I asked phoronix to do it themselves and post results but no response so far.

[Vadi]

Sorry, mine is a dualcore but I failed to mention that. Would your tweaks will apply?

[Svartalf]

Originally Posted by solca

Hi!
My attention got stuck with FIFO and RR which make the process run until it sleeps or yields, something very nice for raw performance specially with lots of cores.

Heh... That's nice, but the problem is that when you're running SCHED_FIFO or SCHED_RR, you pin up the CPU- PERIOD. If you have a runaway process or want to stop an application that's running you won't get the opportunity to KILL it, period, because it's not interruptible once you've placed it in one of the "real-time" priority classes. I'll be honest with everyone when I tell you that this isn't the way to getting peak performance, even with multi-core systems.

Just because it seems more interactive or it seems "better" doesn't mean it's actually a good idea. There's a reason WHY you have to be superuser to put a process into one of those scheduling classes.

[Svartalf]

Originally Posted by solca

I don't think it will have any effect as your system is UP (uni-processor), the thing is that is hard for us just simple users benchmark our favorites games, that's why I asked phoronix to do it themselves and post results but no response so far.

It will have an effect, all right. Negative. When you place a process or set thereof (threads) into one of the realtime scheduling classes, they no longer participate in the scheduling process except to get their shot at a run to yield or exit like all the others, per their priority in the system. Placing any non-system critical processes into this mode forces more other processes out of the running and if you place something in there that doesn't have yields in the mix, you can wedge up your box if it doesn't exit- you will not have normal system interaction with anything (keyboard included) and in some states you won't even see interrupts.

There is a reason that you're technically not supposed to be able to set the priority levels in question except as superuser.

This is a bad idea, guys. Honest. This is from someone who professionally develops device drivers for Linux.

[Vadi]

OK thanks, that sounds convincing. I don't feel like killing off the safety for a bit more performance.

[Svartalf]

Originally Posted by Vadi

OK thanks, that sounds convincing. I don't feel like killing off the safety for a bit more performance.

Heh... You can gain most of the performance in a multi CPU system by doing the pinning of affinity.

In something like Quake4 or Doom3 where it doesn't really take advantage of multi-threading, you can pin the keyboard, mouse, etc. to your other CPU in the system. By doing the CPU affinity steps he's suggesting and leaving everything else alone, you'll see most of the claimed boost without tossing a monkey wrench into the works on the scheduling system (which was designed the way it was for a reason...). With a mult-thread capable game, however, you will cause OTHER problems with pinning- you're better leaving it all alone.

[davidletterboyz]

Originally Posted by Svartalf

It will have an effect, all right. Negative. When you place a process or set thereof (threads) into one of the realtime scheduling classes, they no longer participate in the scheduling process except to get their shot at a run to yield or exit like all the others, per their priority in the system. Placing any non-system critical processes into this mode forces more other processes out of the running and if you place something in there that doesn't have yields in the mix, you can wedge up your box if it doesn't exit- you will not have normal system interaction with anything (keyboard included) and in some states you won't even see interrupts.

There is a reason that you're technically not supposed to be able to set the priority levels in question except as superuser.

This is a bad idea, guys. Honest. This is from someone who professionally develops device drivers for Linux.

Yeah, agreed!

In CFS, Modular Scheduling Framework is used to separate the policies:
- sched_rt (real-time: SCHED_RR/SCHED_FIFO): priority 0 to 99
- sched_fair (time-sharing: SCHED_NORMAL): 100 to 139.

Time sharing policy is the actual part of CFS for desktop scheduling. When we run a task in real time priority, other tasks in SCHED_NORMAL priority (normally tasks have nice 0) will be put in wait until real time task finishes executing. This kills interactivity (even nice -19 is still belong to time sharing: priority 100 ).

And of course, only superuser can execute real-time priority. :P