# CFS settings (changing frequency)

## dE_logics

The CFS scheduler switches between active processes/threads at a frequency. The higher the frequency, more the overhead.

Is there anyway I can reduce/increase this frequency? Does the 'timer frequency' in the kernel configuration does the same thing?

----------

## depontius

It's there in kernel features.  I don't have a make menuconfig or make xconfig handy, so I can't tell you where it is.  But the value comes out as:

```
# CONFIG_HZ_100 is not set

# CONFIG_HZ_250 is not set

CONFIG_HZ_300=y

# CONFIG_HZ_1000 is not set

CONFIG_HZ=300

CONFIG_SCHED_HRTICK=y
```

I'm not sure what drives that last one, but it looked as if it might be relevant, and a decent hing.  You also want to configure "tickless"

```
CONFIG_TICK_ONESHOT=y

CONFIG_NO_HZ=y

CONFIG_HIGH_RES_TIMERS=y
```

Again, I'm not sure if all of these are relevant.

I normally run a "tickless" kernel at 300Hz.  That frequency setting is suggested if you do any multimedia stuff, as it's a compromise between frequency and a nice multiple of 60Hz for US or 50Hz for Europe.  The "tickless" means that the kernel won't sit there ticking away every CONFIG_HZ if there's nothing in the runqueue - it'll be really quiet (and lower power) until there's something to do.

----------

## aCOSwt

As depontius wrote, the most efficient settings are indeed CONFIG_HZ and CONFIG_NO_HZ.

Of course, if you decrease the value for CONFIG_HZ, you will get less scheduler overhead but you'll get a less responsive system likely to lead to problems with audio related apps.

If what you are looking for is reducing the scheduler overhead, I warmly suggest you opt for the BFS or have a go on ck-sources.

Compared to plain gentoo-sources, at a given CONFIG_HZ, the overhead from the scheduler is significantly reduced.

----------

## dE_logics

I'm under the impression that 'tickles' means that the kernel supports the tickles feature of the processor.

i.e. when there're no jobs, the processor will not scan continuously to see if new jobs as available or not, instead, an interrupt will be generated by the kernel to tell the processor that a new job is in schedule.

At this stage, the scheduler is not involved, cause there're not multiple tasks in queue.

What I'm asking about is in scenarios when there're multiple running processes in queue, and CFS is managing them. What I think frequency means is that no. of checks per second the scheduler does to see which process/thread should get the CPU (after certain time interval)... so what I make out till now by your responses is that, yes, the timer frequency does control the frequency at which the BFS scheduler maintains and checks the process queue.

----------

## PaulBredbury

I think it's pretty subtle, e.g. BFS has the tweakable rr_interval.

I've done quite a lot of experimentation over the years, to get the smoothest game experience, and have settled on:

432hz (for dual-CPU - 1000hz isn't completely stable)

tickless (negligible effect on performance, if any)

echo 4 > /proc/sys/kernel/rr_interval (using BFS of course)

----------

## depontius

I've never used the BFS.  But the kernel has always had a timer tick.  Every timer tick, the kernel gets interrupted and decides what to do next.  If there's nothing to do, it just goes back to sleep.  If there's only one thing in the runqueue, it goes back to whatever it was doing before getting interrupted.

The tickless kernel actually came from the mainframe.  They were running thousands of virtual instances, and in some circumstances many of those instance were doing nothing but processing timer ticks.  At the aggregate level they realized that they were spending horrible amount of CPU time "doing nothing".  The result was the "tickless kernel."  Ironically, it's greatest value is for the mainframe - and the laptop (and smaller) - opposite ends of the spectrum.  The rest of us benefit, as well.

The processor doesn't have a "tickless" feature.  It's merely a matter of seeing that the runqueue is empty (or has only one job?) and shutting off the timer interrupt.  Then either the system goes quiescent or (presumably) runs that one job.  Whenever there's a real interrupt, things get scheduled.  Assuming the runqueue isn't empty, the timer interrupt gets turned on, and those jobs get scheduled.

----------

## dE_logics

 *depontius wrote:*   

> I've never used the BFS.  But the kernel has always had a timer tick.  Every timer tick, the kernel gets interrupted and decides what to do next.  If there's nothing to do, it just goes back to sleep.  If there's only one thing in the runqueue, it goes back to whatever it was doing before getting interrupted.
> 
> The tickless kernel actually came from the mainframe.  They were running thousands of virtual instances, and in some circumstances many of those instance were doing nothing but processing timer ticks.  At the aggregate level they realized that they were spending horrible amount of CPU time "doing nothing".  The result was the "tickless kernel."  Ironically, it's greatest value is for the mainframe - and the laptop (and smaller) - opposite ends of the spectrum.  The rest of us benefit, as well.
> 
> The processor doesn't have a "tickless" feature.  It's merely a matter of seeing that the runqueue is empty (or has only one job?) and shutting off the timer interrupt.  Then either the system goes quiescent or (presumably) runs that one job.  Whenever there's a real interrupt, things get scheduled.  Assuming the runqueue isn't empty, the timer interrupt gets turned on, and those jobs get scheduled.

 

And if they're scheduled, they are checked (for switching) at an intervals specified by the timer frequency in the kernel config?

Also, are you sure of what you said?

----------

## depontius

If there is scheduling to be done, it's done at the frequency specified in the kernel config.

If there is nothing to do, the timer interrupt is turned off and the CPU does a HALT, or something like it.  It's then up to an interrupt to get things moving, again.

I'm sure about that much.

What I'm not sure about is if the timer interrupt is running if there is only 1 job in the runqueue.  It would seem to me that if there's only one thing to run, just let it run and don't bother trying to schedule until there is more than one.  I don't know if that's what happens, or if it starts scheduling normally when the runqueue is non-zero.

This of course gets messy with multi-core.  Again, theoretically a quad-core could run without timer interrupts with 4 jobs in the runqueue, one per core.  I'm even more doubtful about that one then the single-job.  I believe that there is work going on to quiesce unneeded cores.

----------

## dE_logics

Thanks for clearing that up. I guess the best place to ask this question is in the linux users mailing list.

----------

