sinon le preempt ne sert qu'a limiter l'impression de râmage de ton systeme quand il est chargé,il est donc nutilie sur un multiproc ;)
Faut pas confondre une modification avec ses effets. Le preempt patch ouvre la possibilité au scheduler, dans des cas précis, de changer la tâche en cours sur un processeur à la fin d'un quantum, même lorsque celle-ci est en train d'executer un appel système, chose qui n'était pas possible avant.
Effectivement, on constate une diminution des effets de ramage, mais aussi une diminution du temps de réactivité d'une application à un évènement, même lorsque la machine ne rame pas.
Si de plus on doit comprendre "nutilie" par son anagramme inutile, le raisonnement me parait quelque peut abscon. Le fait d'avoir plusieurs procs limite mais n'empêche pas de se retrouver dans le cas d'un monoproc, i.e. voir les n processeurs chacun "occupés" par des appels systèmes. J'arrive à gagner des performances non
négligeables sur un quadri soumis à une forte charge de requêtes réseaux.
[^] # Re: RT Linux
Posté par Delahaye Matthieu . En réponse à la dépêche Linux embarqué. Évalué à 4.
Faut pas confondre une modification avec ses effets. Le preempt patch ouvre la possibilité au scheduler, dans des cas précis, de changer la tâche en cours sur un processeur à la fin d'un quantum, même lorsque celle-ci est en train d'executer un appel système, chose qui n'était pas possible avant.
Effectivement, on constate une diminution des effets de ramage, mais aussi une diminution du temps de réactivité d'une application à un évènement, même lorsque la machine ne rame pas.
Si de plus on doit comprendre "nutilie" par son anagramme inutile, le raisonnement me parait quelque peut abscon. Le fait d'avoir plusieurs procs limite mais n'empêche pas de se retrouver dans le cas d'un monoproc, i.e. voir les n processeurs chacun "occupés" par des appels systèmes. J'arrive à gagner des performances non
négligeables sur un quadri soumis à une forte charge de requêtes réseaux.