What is sysctl kern.sched.preempt_thresh

I would only tune one, "kern.hz=100" for freebsd running under virtualization.
For the other tunables there must be a good reason, which i have not seen.
 
ralphbsz said:
Do you have data to support that recommendation? Data gathered on FreeBSD, not on Linux? Experience from Linux is somewhere between meaningless and misleading for other operating systems.
Click to expand...
Working on it too, will post some soon, haven't recommended but stated I would use.

Those settings are somewhat parallel to what I have done on Linux.
 
sagsaw said:
kern.eventtimer.periodic=1 (disable tickless)
Click to expand...
I already gave you an explanation what this does (select the mode of operation in which hardware timers are programmed!), this is certainly nothing similar to whatever Linux' "tickless" does, not even remotely.
sagsaw said:
and if FreeBSD has PREMPTION types like Linux has none/voluntary/full
Click to expand...
FreeBSD doesn't have preemption modes but a threshold instead.

Apart from that, what ralphbsz said.
 
After all my questions and some really insightful answers, I am starting a new thread titled:

Moved from Linux to FreeBSD desktop low level configuration experiments and results
 
sagsaw said:
Those settings are somewhat parallel to what I have done on Linux.
Click to expand...
And that is exactly my complaint: The FreeBSD kernel is COMPLETELY DIFFERENT from the Linux kernel. They share ZERO lines of source. They were designed and implemented by different people, with very different experiences and focuses. There is NO expectation that they behave similarly.

Here's my suggestion: the mods should delete these threads. Because assuming that certain optimizations and tunings that happen to work on Linux (and even that is a stretch) also work on FreeBSD is completely wrong.
 

This is all very nice, but I don't know how threads get assigned the pri value, e.g. is it dynamic or fixed per thread? The code is all contained in a single file but requires some sitting down.

Code: 
        /*
         * If the new priority is not better than the current priority there is
         * nothing to do.
         */
        if (pri >= cpri)
                return (0);
        /*
         * Always preempt idle.
         */
        if (cpri >= PRI_MIN_IDLE)
                return (1);
        /*
         * If preemption is disabled don't preempt others.
         */
        if (preempt_thresh == 0)
                return (0);
        /*
         * Preempt if we exceed the threshold.
         */
        if (pri <= preempt_thresh)
                return (1);

And there is this:
Code: 
/*
 * Print the status of a per-cpu thread queue.  Should be a ddb show cmd.
 */
static void __unused
tdq_print(int cpu)
 
Here is a mail with comments regarding should_preempt(...):

Re: more data: SCHED_ULE+PREEMPTION is the problem

www.mail-archive.com www.mail-archive.com

Code: 
The parameters are:

        pri: the priority if the now runnable thread
        cpri: the priority of the thread that currently runs on "this" CPU
        remote: whether to consider preempting a thread on another CPU

The priority values are those displayed by top or ps -l as "PRI", but with an
offset of 100 applied (i.e. pri=120 is displayed as PRI=20 in top).
 
cracauer@ said:

This is all very nice, but I don't know how threads get assigned the pri value, e.g. is it dynamic or fixed per thread? The code is all contained in a single file but requires some sitting down.
Click to expand...
That depends. The pri value is what we see in ps axl, plus 100 I think. For normal timesharing processes it gets computed, in the scheduler, at every couple of clock ticks, according to the interactivity behaviour of that process, with some weird formula.
For idprio and rtprio it is fixed to the id/rtprio value given. For the various kernel threads it should also be fixed to designated values, somewhere in the kernel source.
 
You must log in or register to reply here.
Back
Top