[Tuto][Initié] Noyau linux

[Daemonium]

Ben oui je l'ai lu en entier. En gros il faut que je fasse un apt-get install ncurse (un truc du genre) ?

Quand on lit le tuto, ça à l'air facile...

Bon je vais rééssayer de patcher le noyau, quand même...

[tuXXX]

sous ubuntu (après une recherche sur la page appropriée du site de ubuntu http://packages.ubuntu.com ou qui peut être faite avec "apt-cache search ncurses" ) il faut installer libncurses5-dev ( "apt-get install libncurses5-dev" )

[Daemonium]

C'est en train de compiler

J'espère que j'ai pas fait de conneries... bon de toute façon j'ai aucune donnée à perdre... à part mon fond d'écran et quelques programmes...

On verra bien!

EDIT:

J'abandonne... pour l'instant. En ecrivant qqch dans la section tuning.. j'ai fait un ctrl+alt+back...

En gros ça a fermé gnome, et pis annulé la compilation.

J'ai voulu relancer, mais il m'a dit que je devais refaire la configuration, qui m'a pris 30minutes

Bon... vais peut-être essayer de trouver un module alsa plus récent, peut-être que ça marchera

Parce que c'est que ça qu'il me faut, le son

[Daemonium]

Coucou, je reviens

root@ubuntuMZ:/usr/src/linux # make
 CHK     include/linux/version.h
make[1]: « arch/i386/kernel/asm-offsets.s » est à jour.
 CHK     include/linux/compile.h
 CHK     usr/initramfs_list
 CC      arch/i386/kernel/acpi/boot.o
arch/i386/kernel/acpi/boot.c:457: error: conflicting types for `acpi_register_gsi'
include/linux/acpi.h:432: error: previous declaration of `acpi_register_gsi'
make[2]: *** [arch/i386/kernel/acpi/boot.o] Erreur 1
make[1]: *** [arch/i386/kernel/acpi] Erreur 2
make: *** [arch/i386/kernel] Erreur 2
root@ubuntuMZ:/usr/src/linux #

J'ai ce message lorsque je tente de lancer la compilation, juste après avoir configuré. Je dois aller reconfigurer l'ACPI?

[semionsi]

Je pense que oui

[tuXXX]

root@ubuntuMZ:/usr/src/linux # make
 CHK     include/linux/version.h
make[1]: « arch/i386/kernel/asm-offsets.s » est à jour.
 CHK     include/linux/compile.h
 CHK     usr/initramfs_list
 CC      arch/i386/kernel/acpi/boot.o
arch/i386/kernel/acpi/boot.c:457: error: conflicting types for `acpi_register_gsi'
include/linux/acpi.h:432: error: previous declaration of `acpi_register_gsi'
make[2]: *** [arch/i386/kernel/acpi/boot.o] Erreur 1
make[1]: *** [arch/i386/kernel/acpi] Erreur 2
make: *** [arch/i386/kernel] Erreur 2
root@ubuntuMZ:/usr/src/linux #

J'ai ce message lorsque je tente de lancer la compilation, juste après avoir configuré. Je dois aller reconfigurer l'ACPI?

ça me semble être une erreur du code du noyau...

Tu n'as eu aucune erreur lors du patch?

[Daemonium]

Non, si ce n'est qu'il s'est pas fermé... donc j'ai fermé avec la petite croix pour rouvrir une session terminal, et là j'ai continué...

D'ailleurs je sais pas pourquoi il ne s'est pas fermé

[tuXXX]

Non, si ce n'est qu'il s'est pas fermé... donc j'ai fermé avec la petite croix pour rouvrir une session terminal, et là j'ai continué...

D'ailleurs je sais pas pourquoi il ne s'est pas fermé

comment ça "il ne s'est pas fermé" ?

Tu veux dire que tu as lancé la commande "patch ..." et quelle ne s'est pas terminée?

Si c'est le cas, tu peux réinstaller les sources et (si tu veux) remettre le patch...

Garde le fichier .config pour ne pas avoir à tout refaire...

[Daemonium]

Ben c'est comme s'il avait pas fini, mais y'a eu un message "patched" je crois (en gros j'ai vu qu'il avait fini) pourtant je pouvais rien écrire, il n'y avait plus le "root@ubuntuMZ:/usr/src/linux #"

Donc je sais pas

Donc hier j'ai tenté d'installer depuis les sources .deb . J'ai réussi à créer un noyau Mais lorsque je l'ai mis dans "boot" et que j'ai modifié grub pour booter sur ce dernier, eh ben.... j'ai redémarré, et pis ça marchait pas (y'a eu plein de messages comme quoi....je sais plus, des modules qui correspondent pas , des trucs comme ça.... )

Donc voilà.... j'ai pas beaucoup avancé

[semionsi]

Daemonium tu avait bien fait le make modules_install?

[Daemonium]

Ouioui

Y me semble pas avoir vu d'erreurs, y'a eu juste tout plein d'avertissements dans la compilation, la grosse.

[winwarrior]

lol?

[neologix]

Comme suggéré par Duke, je mets ici une copie de mon post:

Salut à tous (ça faisait longtemps!):

je viens de lire le tuto de remy sur le noyau, et je lis ça:

1.2.3 Reduction du time slice d'un facteur 10.

Les programmes que vous lancez sont decoupes en processus, qui

sont eux memes decoupes en activites ( threads ). Lorsqu'un

processeur execute une thread, on dit qu'il execute une tache (

task ). Le probleme, c'est qu'il ne peut en traiter qu'une a la

fois lorsqu'il est monocore ( ce qui est le cas

actuellement de tous les processeurs x86, aka pc ). Donc, lorsque

vous lancez mozilla et que vous ecoutez votre mp3 favori avec xmms

par exemple, il va falloir remedier a un souci, satisfaire a la fois mozilla et xmms.

Le processeur dispose d'un ordonnanceur qui

va decouper les besoins de xmms et de mozilla en tranches infimes

et leur attribuera un court lap de temps les ressources du processeur. Notez que

ce temps est si court ( cela depend du systeme, mais nous

resterons simples sur cette partie destinee aux debutants ) que

vous ne ressentez pas ce decoupage du temps; la lecture de votre mp3 est fluide.

Il s'ecoule un certain temps entre le moment ou l'ordonnanceur

dit a mozilla "arrete toi un peu histoire que je redonne du

temps a xmms" et le moment ou il dit a xmms " vas y c'est a toi

!". Ce lap de temps est appele time slice.

Etant reduit 10fois sur un noyau 2.6 ( par rapport a un noyau

2.4 ) vous imaginez bien les performances supplementaires...

Sauf erreur de ma part, il se trompe:

le time slice est la durée pendant laquelle un processus est autorisé à s'éxécuter, et pas la durée pendant laquelle on switche d'un processus à l'autre. Ce temps de "latence" est celui de la commutation de contexte, qu'on n'a, il me semble, pas réussi à évaluer précisément.

Donc, le timeslice avait bien été réduit d'un facteur 10 (passant de 10 à 1 ms), mais la conséquence est juste un plus grande réactivité, mais au prix d'une moins bonne "efficacité", puisque le processeur passe 10 fois plus de temps à effectuer des changements de contexte (sauvegarde des registres, etc dans la pile).

D'ailleurs, il me semble que depuis le 2.6.13, il a été ramené à 4ms (250Hz).

En cas d'erreur, merci de me corriger.

neo

[tuXXX]

Comme suggéré par Duke, je mets ici une copie de mon post:

Salut à tous (ça faisait longtemps!):

je viens de lire le tuto de remy sur le noyau, et je lis ça:

Il s'ecoule un certain temps entre le moment ou l'ordonnanceur

dit a mozilla "arrete toi un peu histoire que je redonne du

temps a xmms" et le moment ou il dit a xmms " vas y c'est a toi

!". Ce lap de temps est appele time slice.

Sauf erreur de ma part, il se trompe:

le time slice est la durée pendant laquelle un processus est autorisé à s'éxécuter, et pas la durée pendant laquelle on switche d'un processus à l'autre. Ce temps de "latence" est celui de la commutation de contexte, qu'on n'a, il me semble, pas réussi à évaluer précisément.

Donc, le timeslice avait bien été réduit d'un facteur 10 (passant de 10 à 1 ms), mais la conséquence est juste un plus grande réactivité, mais au prix d'une moins bonne "efficacité", puisque le processeur passe 10 fois plus de temps à effectuer des changements de contexte (sauvegarde des registres, etc dans la pile).

D'ailleurs, il me semble que depuis le 2.6.13, il a été ramené à 4ms (250Hz).

En cas d'erreur, merci de me corriger.

neo

C'est exact, le time slice est le temps alloué pour une tâche avant que le processeur n'en prenne une autre (et ainsi de suite).

http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html

http://www.linux-france.org/prj/jargonf/T/time_slice.html

http://en.wikipedia.org/wiki/Time_slice_multiplexing

Le passage d'une tâche à une autre est à priori forcé par une interruption matérielle (timer) qui permet au noyau de reprendre la main et de choisir une autre tâche.

Pour tous les 2.4 c'était 100 Hz (10ms par tâche), pour les premiers 2.6 on est passé à 1000 (1ms), mais finalement on repasse à 250 car 1000 c'est trop violent pour les portables.

[neologix]

Ouais, 250Hz permettrait de réduire la consommation des portables, mais certains pensent que cette valeur pourrait être trop faible pour les applications multimedia (musique, vidéos, etc).

Je ne tourne pas sous un 2.6.13, je ne peux donc pas juger.

Par contre, c'est vrai que globalement le processeur va être plus efficace, il va gaspiller moins de temps en commutations de contexte.

[neologix]

Tiens, je viens de m'amuser avec le l'I/O scheduler, pour tester cfq:

et bien franchement, je suis étonné: avec anticipatory, si je m'amusais à faire une copie d'un gros fichier, lancer d'autre applications pendant le même temps prenait énormément de temps, et même, konqueror ne pouvait pas se lancer avant la fin de la copie.

Là, il se lance, et assez raidement.

D'ailleurs, c'est peut-être psychologique, mais je trouve ma bécane plus réactive.

le 2.6.13 a apparemment amélioré cfq, si c'est vrai, cela promet.

Je vous tiens au courant.

neo

P.s: pour connaître le scheduler que vous utilisez:

# cat /sys/block/hda/queue/scheduler

pour le changer:

# echo cfq > /sys/block/hda/queue/scheduler

Pour le rendre permanent, ajouter :

elevator=cfq sur la ligne commande de grub (ou LILO)

[Sufflope]

A ce propos quelqu'un connaitrait une sorte de référence des time slices à choisir (maintenant que le 2.6.13 permet facilement ce réglage) en fonction :

* du type de proco (PII PIII PM Athlon etc)

* de l'utilisation (desktop de boulot avec traitement de texte etc, multimedia, serveur...)

* eventuellement du matos autour (quantité de RAM etc, jsais pas dans quelle mesure ça peut jouer)

?

[neologix]

ouais:

(RAM*Fréquence)/âge_du_capitaine

Nan, plus sérieusement, on ne le sait pas vraiment, c'est pour cela que la valeur a changé au cours du temps.

Je dirais que pour un serveur, il vaut mieux 100Hz, ensuite, pour un laptop, entre 1000 et 250, je ne sais pas, il faut tester.

Mais en cas d'usage intensif multimedia, peut-être vaut-il mieux choisir 1000Hz.

[Sufflope]

OK c'est plutôt contradictoire avec ce que j'ai pu constater

Un serveur web qui avait une grosse charge a supporter (et c'était pas une bête de course : Celeron 900 + 512 de RAM) a arrêté ses freeze de 24h environ (mrtg montrait des pointes de load average de plusieurs centaines, avant de plus rien montrer ) quand j'ai changé son 2.4 pour un 2.6.10

Enfin tu me diras y a pas que ça qui change entre les deux noyaux...

[neologix]

OK c'est plutôt contradictoire avec ce que j'ai pu constater

Un serveur web qui avait une grosse charge a supporter (et c'était pas une bête de course : Celeron 900 + 512 de RAM) a arrêté ses freeze de 24h environ (mrtg montrait des pointes de load average de plusieurs centaines, avant de plus rien montrer ) quand j'ai changé son 2.4 pour un 2.6.10

Enfin tu me diras y a pas que ça qui change entre les deux noyaux...

Entre le 2.4 et le 2.6, pas mal de chose ont changé, notamment le scheduler qui scale en O(1).

Ca aide beaucoup.

Après, peut-être que ton disque était mieux supporté, etc.

Le choix du scheduler d'entrées-sorties jour aussi.

Si tu regardes les options du noyaux, il est dit qu'anticipatory (par défaut) peut ramer pas mal avec des bases de données, et qu'il est conseillé d'utiliser deadline dans ce cas.

Enfin, si je dis 100Hz, c'est parce qu'un serveur doit tenir la charge, il ne doit pas faire de changements de contexte à tire-la-rigot.

La science n'est pas une science exacte...

[Sufflope]

Vi j'avais mis deadline (sur mes PC persos en revanche j'utilise cfq)

Pour 100Hz plutot que 1000 justement, ça peut pas être utile pour un serveur de ce type qui a beaucoup de petits accès (c'est un serveur avec un service de forums gratos) d'etre à 1000, plutot qu'à 100 que je réserverais plus pour un serveur qui héberge de gros fichiers et donc a peu de processus mais longs ? (il a a priori moins besoin de switcher nan)

Et sinon, ouais le mieux serait de tester mais bon c'est pas toujours possible

[neologix]

J'ai écrit deux programmes minuscules pour tester des trucs, et j'ai des résultats marrants...

# include <stdio.h>

int main(void)
{
int a;
printf("%p\n", &a);

return 0;
}

A chaque fois que je le lance, j'obtiens une adresse différente (a priori c'est normal, depuis le 2.6.12 et l'introdcution d'aléas dans l'allocation mémoire).

Par contre, avec:

# include <malloc.h>
# include <stdio.h>

int main(void)
{
int *a = (int *) malloc(sizeof(int));
printf("%p\n", a);

return 0;
}

J'obtiens toujours la même adresse ...

En fait, si je comprends bien, il y a de l'aléas pour la pile, mais pas pour le tas, c'est ça?

[neologix]

Bon, pour ceux que ça intéresse (tuXXX si tu m'entends ;-) j'ai fait quelques recherches, et je suis tombé sur ça:

http://lwn.net/Articles/121845/

Pour l'instant, j'ai juste jetté un coup d'oeil, mais ça a l'air d'expliquer ce comportement...

neo

[tuXXX]

Bon, pour ceux que ça intéresse (tuXXX si tu m'entends ;-) j'ai fait quelques recherches, et je suis tombé sur ça:

http://lwn.net/Articles/121845/

Pour l'instant, j'ai juste jetté un coup d'oeil, mais ça a l'air d'expliquer ce comportement...

J'avais un peu cherché et j'avais pas trouvé (bon ok j'ai pas cherché longtemps...)

Ouais c'est pas mal ça explique que à ce moment là (03/02/2005?) c'était en train d'être testé et pas encore efficace (et que ça ne le sera jamais réellement en 32bits).

Mais si on rajoute ça à un système de protection dans le noyau (selinux, grsecurity, etc...) et à l'option -fstack-protector(-all), ça commence à être bien protégé (reste plus qu'à mettre en chroot et exécuter avec des droits restreints chaque serveur et c'est bon...)