[Linux-Biella] che distro per P200?

[andrea_ferraris@libero.it]

> Un 2.6 e' fully preemptive e lo switch nel menuconfig e' tutto meno
> che sbagliato.
> 
> Love: I'll start with a quick explanation of how the patch works. 
> Right now, the kernel is not preemptible. 
> This means that code running in the kernel runs until completion, 
> which is the source of our latency. Although kernel code is well 
> written and regulated, the net result is that we effectively have
>  an unbounded limit on how long we spend in the kernel. 
> Time spent in kernel mode can grow to many hundreds of milliseconds. 
> With some tasks demanding sub-5ms latencies,
>  this non-preemptibility is a problem.
> 
> The preemptible kernel patch changes all this. 
> It makes the kernel preemptible, just like userspace. 
> If a higher priority task becomes runnable, the preempt patch will 
> allow it to run. Wherever it is. We can preempt anywhere, subject to 
> SMP (symmetric multi-processing) locking constraints. 
> That is, we use spinlocks as markers for regions of preemptibility. 
> Of course, on UP (uni-processing) they aren't actually spinlocks, just markers.
> 
> The improvement to response is clear: a high priority task can run 
> as soon as it needs to. This is a requisite of real-time computing, 
> where you need your RT task to run the moment it becomes runnable. 
> But the same effect applies to normal interactive tasks: as soon 
> as an event occurs (such as the user clicking the mouse) that marks 
> it runnable, it can run (subject to the non-preemptible regions, of course).
> 
> There are some counterarguments. The first is that the preemptible 
> kernel lowers throughput since it introduces complexity. Testing 
> has showed, however, that it improves throughput in nearly all 
> situations. My hypothesis is that the same quicker response to 
> events that helps interactivity helps throughput. When I/O data 
> becomes available and a task can be removed from a wait queue 
> and continue doing I/O, the preemptible kernel allows it to 
> happen immediately -- as soon as the interrupt that set 
> need_resched returns, in fact. This means better multitasking.
> 
> There are other issues, too. We have to take care of per-CPU 
> variables, now. In an SMP kernel, per-CPU variables are 
> "implicitly locked" -- they don't have explicit locks but 
> since they are unique to each CPU, a task on another CPU 
> can't touch them. 
> Preemption makes it an issue since a preempted task can trample 
> on the variables without locks.
> 
> Overall I think the issues can be addressed and we can have a 
> preemptible kernel as a proper solution to latency in the kernel.

Grazie 1000!!

Giusto per terminare da dove era iniziata la cosa, nel 2.4 di gentoo, sono state
aggiunte (da diversi mesi) delle patch per renderlo preemptive.
I risultati si vedevano gia` allora:
http://www.gentoo.org/main/en/performance.xml
e quindi e` probabilmente fra le piu` indicate - nonostante il kernel 2.4.X -
per un hardware del tipo di quello di cui si discuteva.

Andrea