Tickless mode and kern.hz

S

sagsaw

setting

kern.eventtimer.periodic=0

which means kernel is tickless

does this really mean that kern.hz has no effect?

13.1 default is tickless but kern.hz is also set to 1000
 
BTW, trying to give you a somewhat longer answer, first the TL;DR:
sagsaw said:
does this really mean that kern.hz has no effect?
Click to expand...
-> No. <-

kern.hz tells the frequency of timer interrupts. kern.eventtimer.periodic configures one "mode of operation" for actual hardware timers. These are orthogonal.

An OS needs timers for many purposes, two of them being scheduling of tasks (including preemption) and updating the system clock. This can't work reliably without at least one timer "firing" at a fixed rate.

Different platforms have different hardware providing timer functionality, but it's pretty common that some hardware can trigger an interrupt on any timer underrun, and that the timer can be configured to be "periodic" (so the hardware automatically reloads the start value on underrun) or "one-shot" (so, the timer must be actively started again by software after underrun). All the sysctl you're asking about does is configure the preferred mode of operation for using hardware timers. "one-shot" is preferred according to the manpage, probably because it gives greater flexibility. One example I could think about is that some CPU currently idle doesn't need to receive timer interrupts, it would just waste a bit of energy. As long as the interrupt is generated on one of the system's CPUs, that will be enough for the kernel.

Now, I have really no idea what Linux' "tickless" option does in practice. It certainly can't disable any timer interrupts, the system wouldn't work any more. It must still make sure the clock can run at a monotonic rate, for example. And btw, same for FreeBSD, I didn't have a deep look into kernel code what kinds of optimizations might be done here programming the actual timer hardware (depending on the target platform).

And this brings me back to my short answer above: Why do you feel the need to "tune" anything here? If you don't have an actual problem to solve, if it's "tuning just because" – don't do it. That's never a good idea.
 
May I suggest that the OP read (a) the black book, and (b) the source code? They are asking questions about complex kernel mechanisms, and tuning those without understanding how they work internally is unlikely to be satisfactory.

I also completely agree with Zirias' question: Why?
 
zirias@ said:
And this brings me back to my short answer above: Why do you feel the need to "tune" anything here? If you don't have an actual problem to solve, if it's "tuning just because" – don't do it. That's never a good idea.
Click to expand...
I done a few changes when I was using Linux wrt schedulars timer interrupt at the very least

was trying to check parallels in FreeBSD and just blanket apply my Linux values to FreeBSD and check out before deep diving into the needs and then actually tuning it if required.
 
ralphbsz said:
complex kernel mechanisms
Click to expand...
Indeed. Even how hardware-timers are used and interrupts are generated is a complex thing nowadays ;)

Anecdotal, the only platform that I can claim to fully understand without outright lying -- the C64 -- already uses some timer hardware for the (back then: only) "system interrupt". The C64 KERNAL (sic!) configures it for periodic mode and ~50Hz. Not even a possibility to "tune" anything back then :cool:
 
sagsaw said:
I done a few changes when I was using Linux wrt schedulars timer interrupt at the very least

was trying to chech parallels in FreeBSD and just blanket apply my Linix values to FreeBSD and check out before deep diving into the needs and then actually tuning it if required.
Click to expand...
I thought so. It's not a good idea. Linux has a history of scheduler issues. I remember some (well, quite some) time back when Linux 2.x was the current release version, some patches by Con Kolivas that completely replaced the scheduler helped a lot with desktop performance. And I'm still baffled Linux has options(!) to pick an I/O scheduler (or is this gone by now?)

In my experience, FreeBSD (including its scheduler) "just works". You might want to use rtprio(1) (idprio) in rare cases if something needs always/never priority over other stuff, and this, as well, just works. You might want to tune kern.sched.preempt_thresh up or down, to change the balance between (CPU-)throughput and responsiveness, but don't just do it blindly, the default is a good compromise. Other than that, just test the system as is with all its defaults, you will most likely be satisfied.
 
bakul said:
FreeBSD does not run tickless.
Click to expand...
Whatever that means. Do you have any source with an actual technical explanation what Linux is really doing in that mode? I'm almost sure the term is at least misleading; as I stated above, an OS can't run correctly without any timer interrupts. You *could* try to come up with a scheme that adapts the frequency based on load or whatever, which is complex for example to keep the clock monotonic, but seems doable, my guess would be it's along these lines....
 
IIRC, Linux runs tickless (when configured) for CPU with singleton run queues or when there's a runnable process with dominant realtime priority.
 
zirias@ said:
Whatever that means. Do you have any source with an actual technical explanation what Linux is really doing in that mode? I'm almost sure the term is at least misleading; as I stated above, an OS can't run correctly without any timer interrupts. You *could* try to come up with a scheme that adapts the frequency based on load or whatever, which is complex for example to keep the clock monotonic, but seems doable, my guess would be it's along these lines....
Click to expand...

This explains the tickless/dynticks in linux.
 
zirias@ said:
I thought so. It's not a good idea. Linux has a history of scheduler issues. I remember some (well, quite some) time back when Linux 2.x was the current release version, some patches by Con Kolivas that completely replaced the scheduler helped a lot with desktop performance. And I'm still baffled Linux has options(!) to pick an I/O scheduler (or is this gone by now?)

In my experience, FreeBSD (including its scheduler) "just works". You might want to use rtprio(1) (idprio) in rare cases if something needs always/never priority over other stuff, and this, as well, just works. You might want to tune kern.sched.preempt_thresh up or down, to change the balance between (CPU-)throughput and responsiveness, but don't just do it blindly, the default is a good compromise. Other than that, just test the system as is with all its defaults, you will most likely be satisfied.
Click to expand...
Linux has come a long way from 2.4.

6.1 is LTS support current Linux.

CPU Schedular and IO Schedular are different in Linux.

Currently
 
jb82 said:
IIRC, Linux runs tickless (when configured) for CPU with singleton run queues or when there's a runnable process with dominant realtime priority.
Click to expand...
If you want to make such strange things (witch I think is most use full if you are doing only one task, and really want the system in a specific way) look for instance here https://man.freebsd.org/cgi/man.cgi?renice(8) or https://man.freebsd.org/cgi/man.cgi?query=setpriority&sektion=2&manpath=freebsd-release-ports Remember only root can run like that.

What are you doing that is so special that it requires all that thinkering ?? Just out of curiosity :)
 
Ok, after some testing, freebsd is indeed "tickless". Earlier I was wrong (had assumed this area had not changed). You should be able to get usleep(n) to work fairly accurately for very small values of n, assuming kern.eventtimer.periodic is 0 (the default).
 
For a desktop, I would use the tickless dynticks but for server I wouldnt want the CPU to remain idle and have context switching eat up time and throughput.

Of course need to also know if Linux like preemption types are there in FreeBSD
none/voluntary/full so that none can be chosen for servers and voluntary for desktop and full for multimedia and gaming
 
sagsaw said:
Is ULE both a CPU and IO Schedular???
Click to expand...
My opinions, my understanding, may not be 100% technically accurate.

ULE is a scheduler that schedules processes (tasks, threads, whatever subunit of execution you want to call) that takes CPU and IO into consideration when recalculating "who runs next on what cpu". Pretty much like every other scheduler I know about.

The default values used to tune the scheduler do a reasonable jobs across a wide variety of loads, perhaps biased towards servers. For any specific load it may be desirable to tune it a little bit. Plenty of threads here discussing it.
I have mucked about with some of the tunables, really haven't noticed much difference (standard desktop use: browsers, editors, etc) have wound up with the following in /etc/sysctl.conf that "may" make a difference. I'm saying "may" because some days I think I see a huge difference, most days no difference.

kern.timecounter.hardware="HPET"
kern.sched.steal_thresh=1
machdep.idle=mwait

sagsaw said:
Of course need to also know if Linux like preemption types are there in FreeBSD
none/voluntary/full so that none can be chosen for servers and voluntary for desktop and full for multimedia and gaming
Click to expand...
This is a rabbit hole that often leads to one feeling like Alice meeting the Red Queen.
there are sysctls that let you adjust preemption and preemption threshhold that can likely be used to emulate Linux behavior, but my personal opinion:
You are better off running with the default values under your specific workloads and seeing what is good and what is bad. Trying to go through and "pretune a system you haven't run on real hardware" sounds very unintuitive to me.
 
larshenrikoern said:
If you want to make such strange things (witch I think is most use full if you are doing only one task, and really want the system in a specific way) look for instance here https://man.freebsd.org/cgi/man.cgi?renice(8) or https://man.freebsd.org/cgi/man.cgi?query=setpriority&sektion=2&manpath=freebsd-release-ports Remember only root can run like that.

What are you doing that is so special that it requires all that thinkering ?? Just out of curiosity :)
Click to expand...
I'm not OP, just added my two cents :)
 
You must log in or register to reply here.
Back
Top