You can make some tradeoffs with kernel options. Which one you
choose is up to you (assuming it's your personal machine). In
"make menuconfig" go to...
General setup -->
Preemption Model --->
You have 3 choices. The 1st choice will probably finish your
rendering fastest, but other programs will have problems breaking in for
a timeslice. This will look like freezing. The 3rd choice will give
the most possibility for other programs to preempt, but will run
slightly slower overall. The 2nd choice is a compromise. Assuming
you're the admin of the machine, the choice is up to you. Sorry, "you
can't have your cake and eat it too".
1) "No Forced Preemption (Server)"; manual version "CONFIG_PREEMPT_NONE"
> This is the traditional Linux preemption model, geared towards
> throughput. It will still provide good latencies most of the time,
> but there are no guarantees and occasional longer delays are possible.
>
> Select this option if you are building a kernel for a server or
> scientific/computation system, or if you want to maximize the raw
> processing power of the kernel, irrespective of scheduling latencies.
2) "Voluntary Kernel Preemption (Desktop)"; "CONFIG_PREEMPT_VOLUNTARY"
> This option reduces the latency of the kernel by adding more
> "explicit preemption points" to the kernel code. These new
> preemption points have been selected to reduce the maximum latency
> of rescheduling, providing faster application reactions, at the
> cost of slightly lower throughput.
>
> This allows reaction to interactive events by allowing a low
> priority process to voluntarily preempt itself even if it is in
> kernel mode executing a system call. This allows applications to
> run more 'smoothly' even when the system is under load.
3) "Preemptible Kernel (Low-Latency Desktop)"; "CONFIG_PREEMPT"
> This option reduces the latency of the kernel by making all kernel
> code (that is not executing in a critical section) preemptible.
> This allows reaction to interactive events by permitting a low
> priority process to be preempted involuntarily even if it is in kernel
> mode executing a system call and would otherwise not be about to reach
> a natural preemption point. This allows applications to run more
> 'smoothly' even when the system is under load, at the cost of slightly
> lower throughput and a slight runtime overhead to kernel code.
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
