1 |
Hi Walter, |
2 |
|
3 |
thanks for your input again. |
4 |
|
5 |
A said previously: This is not a problem of a high load, |
6 |
which needs to be handled. This is kinda temporary deadlock. |
7 |
Even if I would choose the best possible scheduler...the |
8 |
CPU would not get the chance to execute the code of the scheduler, |
9 |
because something locks the system. This description is meant to |
10 |
describe the situation more than to describe the exact technical |
11 |
background, for which I still search a solution to avoid it completly. |
12 |
|
13 |
In the moment everything runs fine again, without haveing changed |
14 |
any kernel configuration or anything else actively. /Something/ |
15 |
must have changed, though. |
16 |
|
17 |
Cheers! |
18 |
Meino |
19 |
|
20 |
|
21 |
On 05/06 02:23, Walter Dnes wrote: |
22 |
> You can make some tradeoffs with kernel options. Which one you |
23 |
> choose is up to you (assuming it's your personal machine). In |
24 |
> "make menuconfig" go to... |
25 |
> |
26 |
> General setup --> |
27 |
> Preemption Model ---> |
28 |
> |
29 |
> You have 3 choices. The 1st choice will probably finish your |
30 |
> rendering fastest, but other programs will have problems breaking in for |
31 |
> a timeslice. This will look like freezing. The 3rd choice will give |
32 |
> the most possibility for other programs to preempt, but will run |
33 |
> slightly slower overall. The 2nd choice is a compromise. Assuming |
34 |
> you're the admin of the machine, the choice is up to you. Sorry, "you |
35 |
> can't have your cake and eat it too". |
36 |
> |
37 |
> 1) "No Forced Preemption (Server)"; manual version "CONFIG_PREEMPT_NONE" |
38 |
> |
39 |
> > This is the traditional Linux preemption model, geared towards |
40 |
> > throughput. It will still provide good latencies most of the time, |
41 |
> > but there are no guarantees and occasional longer delays are possible. |
42 |
> > |
43 |
> > Select this option if you are building a kernel for a server or |
44 |
> > scientific/computation system, or if you want to maximize the raw |
45 |
> > processing power of the kernel, irrespective of scheduling latencies. |
46 |
> |
47 |
> 2) "Voluntary Kernel Preemption (Desktop)"; "CONFIG_PREEMPT_VOLUNTARY" |
48 |
> |
49 |
> > This option reduces the latency of the kernel by adding more |
50 |
> > "explicit preemption points" to the kernel code. These new |
51 |
> > preemption points have been selected to reduce the maximum latency |
52 |
> > of rescheduling, providing faster application reactions, at the |
53 |
> > cost of slightly lower throughput. |
54 |
> > |
55 |
> > This allows reaction to interactive events by allowing a low |
56 |
> > priority process to voluntarily preempt itself even if it is in |
57 |
> > kernel mode executing a system call. This allows applications to |
58 |
> > run more 'smoothly' even when the system is under load. |
59 |
> |
60 |
> 3) "Preemptible Kernel (Low-Latency Desktop)"; "CONFIG_PREEMPT" |
61 |
> |
62 |
> > This option reduces the latency of the kernel by making all kernel |
63 |
> > code (that is not executing in a critical section) preemptible. |
64 |
> > This allows reaction to interactive events by permitting a low |
65 |
> > priority process to be preempted involuntarily even if it is in kernel |
66 |
> > mode executing a system call and would otherwise not be about to reach |
67 |
> > a natural preemption point. This allows applications to run more |
68 |
> > 'smoothly' even when the system is under load, at the cost of slightly |
69 |
> > lower throughput and a slight runtime overhead to kernel code. |
70 |
> |
71 |
> -- |
72 |
> Walter Dnes <waltdnes@××××××××.org> |
73 |
> I don't run "desktop environments"; I run useful applications |
74 |
> |