[Linux-Biella] che distro per P200?

[CIARROCCHI, Paolo, VF-IT]

From: Marco Ermini [mailto:markoer@markoer.org] 

> > A il preemptible del 2.6 lo e' a priori, nel
> > senso che a un certo time-slice, preempta in ogni caso, 
> senza aspettare la
> > chiusura delle f()
> 
> Ci possono essere milioni di algoritmi, ma comunque, ripeto, 
> sono tutti
> preempitive nel momento in cui non sono collaborative. Non è che se
> Torvalds aggiunge uno switch nel menuconfig con una 
> terminologia sbagliata
> tutta l'informatica deve seguire a ruota... l'informatica mica è
> Torvalds-centrica! :-)


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.


			Paolo