Encore plus à la bourre que prévu : 2.6.10-ck4 out
[fixed]I recommend all ck3 users upgrade.
2.6.10-ck3 was a brown paper bag release. A poorly considered last
minute change made for some odd starvation problems. For this release I
rewrote a large section of the staircase code that had been troubling me
and been getting steadily worse. In the process I’ve made the semantics
of resuming an old timeslice much simpler and more predictable.
Changed:
-cfq-ts-19g.diff
+cfq-ts-20.diff
Jens’ latest incarnation of the cfq-timeslices patch with i/o priority
support for read and write has much smoother read vs write
characteristics now.
AC : le nouvel noyau est sorti :
[fixed]2.6.10-ac9
2.6.10 variant of the stack race fix (Alan Cox)
| Found by Paul Staretz
Stronger ELF validity checks (Solar Designer)
Add ATI SATA identifiers (Frederick Li)
o Update ATI PATA/SATA support (Frederick Li)
Audit fixups (Steve Grubb, Roger Luethi)
FPU/signal handling fix (Bodo Stroesser)
nForce2 APIC/LAPIC errata fixup (Prakash Punnoor)
Swap aacraid fix in -ac with 2.6.11rc base fix (Tom Coughlan)
Connnection track/rst fix (Martin Josefsson)
o Format ide printk’s more nicely (Gunther Mayer)
o Stallion serial resurrection (part one) (Wayne Meissner)
Fix nls_ascii (Ogawa Hirofumi)
Count writeback pages in nr_scanned (Rik van Riel)
| OOM fixing
o Revert ac97_patch changes (Jules Villard)
| with this change many users get no sound out
o Correct handling of some module parameter (Rusty Russell)
errors[/fixed]
Au fait, dans le 2.6.11, y a un « remove the big kernel lock »… En français, ça veut dire quoi ? (PS : c’est ptêt ça qui empêche mon nVidia de tourner ?)
Le Big kernel lock (BKL) est un lock qui permet de bloquer l’activité de tout le kernel pour faire une opération.
Les locks sont très utilisés pour gérer la concurence (2 fonctions aui veulent accéder à la même ressource en même temps…)
En général on utilise de ‹ petits › locks dont la visibilité est locale (seulement la donnée/préiphérique considéré) ou des locks plus gros : l’accé à un CPU est bloqué le temps d’une opération.
Pour simplifier la gestion du multi cpu dans les noyaux 2.4 certaines opérations (migrations de processus, vfs… )étaient sous BKL, c’est à dire toutes les opérations sont suspendues le temps qu’une fonction s’achève.
C’est assez inefficace! Simple à programmer, mais on perd du temps. Pendand qu’une fonction s’exécute sous BKL aucune autre fonction, sur n’importe quel CPU n’est active, on se retrouve en monotâche, monocpu… pendant quelques opérations.
Moins il y a de BKL mieux c’est, même si des fois on n’a pas d’autres choix que de tout suspendre pour être sur de ne pas corrompre nos données.
ah ouais, je commence à comprendre ces histoires de temps réel et de locks (j’avais lu un article dans linux+dvd, mais j’avais pas tout compris => v_atekor, t’explique mieux qu’eux ;))
surtout que dans le noyau que j’utilise (nitro-sources), y a une entrée ‹ Preempt Big Kernel Lock › dans le menuconfig… et que je l’ai cochée puisqu’ils ne disaient pas de ne pas le faire
Le as2 est sorti le 16/01
[fixed]2.6.10-as2
De:
Andres Salomon dilinger@voxel.net
Date:
Dimanche 16 Janvier 2005 08:00:16
Forums:
linux.kernel
aucune référence
Hi,
Here’s 2.6.10-as2. Not too many changes, as I’m still going through
past bk changesets. As requested by numerous people, I’m including the
changelog in the email (between -as1 and -as2); the full changelog is
available at the url below. Thank you to the numerous people who
offered suggestions, fixes, and moral support.
« I’m announcing a new kernel tree; -as. The goal of this tree is to form a stable base for vendors/distributors to use for their kernels. » C’est bien ça!
v_atekor : merci pour la clareté de l’explication
" je commence à comprendre ces histoires de temps réel et de locks" : linux n’est pas temps réel. Si vous avez un oscillo sous la main, générez un signal carré sur le port // (10 lignes de C), monter doucement en fréquence et observer la cata au dessus d’une certaine fréquence.
Ils avaient pas parlé de « virtualisation » aussi dans le 2.7 ?
Dîtes, est-ce que le BKL pourrait être à la source d’un non fonctionnement des drivers nVidia ? Chez moi, le module compile et se charge correctement mais l’écran reste noir lorsque je lance Xorg (même un ctrl+alt+F1 n’y fait rien…)
Pas tout à fait si loin
Mais il y a des choses en préparation, le tout est de savoir si on forke les 2.6 ou si on fait une évolution continue sur les 2.6…
En fait on forke on a des équipes qui bossent sur les versions de dev, d’autres sur la version stable et d’autres encore qui font du back port des fcontions de la nouvelle branche vers l’ancienne : c’est coûteux, pas trop efficace…
J’aime assez le système de dévelo actuel du 2.6 mais si on le rend « temps réel hard », il mériterait de s’appeler 3.0 rien que pour ça!! Je suis peut être biasé par mon intéret pour l’embarqué…
Sans doute… Mais Linus dit que le temps réel hard (avec n’importe quelle borne sup.) est contradictoire fondamentalement avec Unix
Je ne comprends pas pourquoi, mais bon, ça risque de batailler ferme un bon moment avant que les patchs RT soit acceptés… ils existent déjà en fait, mais le père linus les a refusé.
:
=> v_atekor, t’explique mieux qu’eux ;))