Working on it too, will post some soon, haven't recommended but stated I would use.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.
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.kern.eventtimer.periodic=1 (disable tickless)
FreeBSD doesn't have preemption modes but a threshold instead.and if FreeBSD has PREMPTION types like Linux has none/voluntary/full
https://linuxconfig.net/reviews/freebsd-9-0-review.htmlI 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.
FreeBSD doesn't have preemption modes but a threshold instead.
Apart from that, what ralphbsz said.
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.Those settings are somewhat parallel to what I have done on Linux.
/* * 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);
/* * Print the status of a per-cpu thread queue. Should be a ddb show cmd. */ static void __unused tdq_print(int cpu)
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).
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.