Advanced Search

Shh tommy, you're going to push up the price of T series Lenovos . Us poor sods on limited funds may not be able to afford the toughest laptops built, definitely better built than the discs in my spine . I've had my T530 pro-covid, maybe a year or 2 and it does everything I need it to do.

Preemption ModelsThe various preemption models are kernel specific. In principle, user space programs are always preemptible.Preemption of a running task is performed by the scheduler. This action can be triggered by a kernel interaction like a system call or an asynchronous event like an interrupt. The scheduler saves the context of the preempted task and restores the context of the new task.The Linux kernel implements several preemption models. The desired model is selected at build time of the kernel. The “Fully Preemptible Kernel” preemption model must be selected to obtain Linux as an RTOS. For the sake of completeness a list and a short explanation of the existing Linux preemption models is given. The last two entries are available only with the PREEMPT_RT patch.

• No Forced Preemption (server) – the traditional Linux preemption model, geared towards throughput . System call returns and interrupts are the only preemption points.
• Voluntary Kernel Preemption (Desktop) – reduces the latency of the kernel by adding more “explicit preemption points” to the kernel code [. . . ] at the cost of slightly lower throughput . In addition to explicit preemption points, system call returns and interrupt returns are implicit preemption points.
• Preemptible Kernel (Low-Latency Desktop) – reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. An implicit preemption point is located after each preemption disable section.
• Preemptible Kernel (Basic RT) – resembles the “Preemptible Kernel (Low-Latency Desktop)” model. Besides the properties mentioned above, threaded interrupt handlers are forced (as when using the kernel command line parameter

  threadirqs

  ). This model is mainly used for testing and debugging of substitution mechanisms implemented by the PREEMPT_RT patch.
• Fully Preemptible Kernel (RT) – all kernel code is preemptible except for a few selected critical sections. Threaded interrupt handlers are forced. Furthermore several substitution mechanisms like sleeping spinlocks and rt_mutex are implemented to reduce preemption disabled sections. Additionally, large preemption disabled sections are substituted by separate locking constructs. This preemption model has to be selected in order to obtain real-time behavior.

The above was taken from here: wiki.linuxfoundation.org/realtime/docume...cs/preemption_models

I was wanting to know a little bit about the models. I would opine that the last model would be the one most appropriate for Linuxcnc.

 
Without those patches there is no choice for a fully-preemptible kernel. With the patch, however as shown above, you can. Kernel I'm working on is 6.1.69. The rpi-linux 6.1.y tree is currently at 6.1.93 but there are no patches for that kernel version. Even with the 6.1.69 kernel I had to add a supports rt patch.

Once I get 6.1.y working I'll investigate the 6.12.y branch.

These are the kernel versions supported by the 6.1.y branch, first number can be ignored, anything lower than 6.1.93 will need to be checked out via it's commit hash.
134:    Linux 6.1.93
14291:    Linux 6.1.92
16232:    Linux 6.1.91
23660:    Linux 6.1.90
27681:    Linux 6.1.89
27706:    Linux 6.1.88
32471:    Linux 6.1.87
35109:    Linux 6.1.86
37360:    Linux 6.1.85
42147:    Linux 6.1.84
50699:    Linux 6.1.83
62988:    Linux 6.1.82
64939:    Linux 6.1.81
71599:    Linux 6.1.80
77453:    Linux 6.1.79
84250:    Linux 6.1.78
86343:    Linux 6.1.77
92914:    Linux 6.1.76
99084:    Linux 6.1.75
110569:    Linux 6.1.74
113192:    Linux 6.1.73
113387:    Linux 6.1.72
118104:    Linux 6.1.71
120743:    Linux 6.1.70
124909:    Linux 6.1.69
128698:    Linux 6.1.68
134527:    Linux 6.1.67
134563:    Linux 6.1.66
138000:    Linux 6.1.65
140685:    Linux 6.1.64
152972:    Linux 6.1.63
163065:    Linux 6.1.62
164790:    Linux 6.1.62
166577:    Linux 6.1.61
169429:    Linux 6.1.60
175826:    Linux 6.1.59
179923:    Linux 6.1.58
180151:    Linux 6.1.57
184954:    Linux 6.1.56
195377:    Linux 6.1.55
200028:    Linux 6.1.54
207409:    Linux 6.1.53
223634:    Linux 6.1.52
224553:    Linux 6.1.51
225079:    Linux 6.1.50
229388:    Linux 6.1.49
229507:    Linux 6.1.48
229985:    Linux 6.1.47
235916:    Linux 6.1.46
240487:    Linux 6.1.45
244966:    Linux 6.1.44
245843:    Linux 6.1.43
252366:    Linux 6.1.42
259059:    Linux 6.1.41
259111:    Linux 6.1.40
266071:    Linux 6.1.39
283243:    Linux 6.1.38
283669:    Linux 6.1.37
284688:    Linux 6.1.36
289556:    Linux 6.1.35
294854:    Linux 6.1.34
298872:    Linux 6.1.33
305346:    Linux 6.1.32
306760:    Linux 6.1.31
310746:    Linux 6.1.30
319815:    Linux 6.1.29
326982:    Linux 6.1.28
344147:    Linux 6.1.27
345004:    Linux 6.1.26
348476:    Linux 6.1.25
352380:    Linux 6.1.24
357625:    Linux 6.1.23
363409:    Linux 6.1.22
370947:    Linux 6.1.21
377351:    Linux 6.1.20
395818:    Linux 6.1.19
395937:    Linux 6.1.18
401889:    Linux 6.1.17
401945:    Linux 6.1.16
426850:    Linux 6.1.15
428063:    Linux 6.1.14
429689:    Linux 6.1.13
433231:    Linux 6.1.12
436893:    Linux 6.1.11
443093:    Linux 6.1.10
452670:    Linux 6.1.8
458562:    Linux 6.1.7
463817:    Linux 6.1.6
464240:    Linux 6.1.5
469413:    Linux 6.1.4
475708:    Linux 6.1.3
479044:    Linux 6.1.2
509801:    Linux 6.1.1
513771:    Linux 6.1-rc8
518375:    Linux 6.1-rc7
527180:    Linux 6.1-rc6
535363:    Linux 6.1-rc5
545612:    Linux 6.1-rc4
554317:    Linux 6.1-rc3
565192:    Linux 6.1-rc2
576296:    Linux 6.1-rc1
871669:    Linux 6.1.

 

JT wrote:

Messing around with QLinearGradients and thinking of adding them to the Stylesheet Builder.

Is it worth it?

JT
 

A gradient would be good for something like a progressbar unless there's some other way to express zones.

Was messing with the qss builder a bit.....it definately needs an "open" function.

Also doesn't seem to be any way to apply the background colors. I assumed this would be part of "All" but it doesn't seem to work like that.

 

Like you assumed before I think those patches indeed didn't make it to the mainline kernel, but those are not needed to make a fully preemptible kernel.

The sysfs patch is only needed because LinuxCNC checks that indicator. Later I saw that the source of Raspberry also already has the arch_supports_rt in the kconfig.