Grosses ecritures disque sous debian : ralentissements
12 réponses
Francois-Philippe Il Grande
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la
pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque
dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps
puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois
l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye
d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a
intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas
parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce
probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un
grand secour.
Francois-Philippe Il Grande nous a gentiment écrit:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Je ne sais pas si cela t'aidera mais le planete linux d'avril en parle:
Debian tourne sous hurd K2; pas sous linux. Les 2 noyaux sont antagonistes. -- Thierry de Champagne Le pays où les bulles font la fête
Francois-Philippe Il Grande nous a gentiment écrit:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais
je la pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le
disque dur, hors sous debian, les ecritures sont bufferisees pendant un
certain temps puis pratiquement tout s'arrete le temps d'ecrire sur le
disque et, une fois l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai
essaye d'utiliser l'appel systeme fsync (force l'ecriture) dans mon
programme a intervalle regulier, cela ameliore sensiblement le probleme
mais ce n'est pas parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce
probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour
ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait
d'un grand secour.
Je ne sais pas si cela t'aidera mais le planete linux d'avril en parle:
Debian tourne sous hurd K2; pas sous linux. Les 2 noyaux sont antagonistes.
--
Thierry de Champagne
Le pays où les bulles font la fête
Francois-Philippe Il Grande nous a gentiment écrit:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Je ne sais pas si cela t'aidera mais le planete linux d'avril en parle:
Debian tourne sous hurd K2; pas sous linux. Les 2 noyaux sont antagonistes. -- Thierry de Champagne Le pays où les bulles font la fête
Stéphane ACOUNIS
Le Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande a écrit:
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
-- Stéphane ACOUNIS
Le Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande a écrit:
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait
d'un grand secour.
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose
ici que c'est un disque IDE).
Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les
choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons
paramètres. RedHat le fait par défaut.
Le Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande a écrit:
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
-- Stéphane ACOUNIS
Francois-Philippe Il Grande
On Sun, 13 Jul 2003 19:22:31 +0200 Stéphane ACOUNIS wrote:
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose
ici que c'est un disque IDE).
Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les
choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons
paramètres. RedHat le fait par défaut.
On Sun, 13 Jul 2003 19:22:31 +0200 Stéphane ACOUNIS wrote:
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
Non, le DMA est bien actif et en UDMA5.
-- Frog
Stéphane ACOUNIS
Le Sun, 13 Jul 2003 20:53:38 +0200, Francois-Philippe Il Grande a écrit:
On Sun, 13 Jul 2003 19:22:31 +0200 Stéphane ACOUNIS wrote:
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
Non, le DMA est bien actif et en UDMA5.
Tu es sûr? Que dit "cat /proc/ide/le_chipset_qui_va_bien" ?
-- Stéphane ACOUNIS
Le Sun, 13 Jul 2003 20:53:38 +0200, Francois-Philippe Il Grande a écrit:
Il y a fort à parier que le DMA n'est pas actif sur le disque (je
suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1
/dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local
quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
Non, le DMA est bien actif et en UDMA5.
Tu es sûr? Que dit "cat /proc/ide/le_chipset_qui_va_bien" ?
Le Sun, 13 Jul 2003 20:53:38 +0200, Francois-Philippe Il Grande a écrit:
On Sun, 13 Jul 2003 19:22:31 +0200 Stéphane ACOUNIS wrote:
Il y a fort à parier que le DMA n'est pas actif sur le disque (je suppose ici que c'est un disque IDE). Un petit coup de "hdparm -d1 -c1 /dev/hda" va sûrement arranger les choses. À mettre dans /etc/rc.local quand tu auras trouvé les bons paramètres. RedHat le fait par défaut.
Non, le DMA est bien actif et en UDMA5.
Tu es sûr? Que dit "cat /proc/ide/le_chipset_qui_va_bien" ?
-- Stéphane ACOUNIS
Julien `soda` Delange
On Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande wrote:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Avant toute chose, j'ai une question ... Quel est votre chipset IDE ? De plus, ce probleme ne doit pas etre spécifique à Debian, car apres tout, il utilise une base qui est standard sur toutes les distributions (je veux bien entendu parler du noyau Linux).
Cordialement,
On Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande wrote:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la
pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque
dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps
puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois
l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye
d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a
intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas
parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce
probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un
grand secour.
Avant toute chose, j'ai une question ... Quel est votre chipset IDE ?
De plus, ce probleme ne doit pas etre spécifique à Debian, car apres tout,
il utilise une base qui est standard sur toutes les distributions (je veux
bien entendu parler du noyau Linux).
On Sun, 13 Jul 2003 18:10:20 +0200, Francois-Philippe Il Grande wrote:
Bonjour,
je ne suis pas sur d'etre sur le bon newsgroup pour cette question, mais je la pose quand meme.
J'ai ecrit un programme qui doit effectuer de grosses ecritures sur le disque dur, hors sous debian, les ecritures sont bufferisees pendant un certain temps puis pratiquement tout s'arrete le temps d'ecrire sur le disque et, une fois l'ecriture terminee, ca recommence a bufferiser.
Le probleme c'est que je dois ecrire en temps reel sur le disque, j'ai essaye d'utiliser l'appel systeme fsync (force l'ecriture) dans mon programme a intervalle regulier, cela ameliore sensiblement le probleme mais ce n'est pas parfait.
La raison pour laquelle je poste cette question ici est que je n'ai pas ce probleme sous Redhat, donc il doit y avoir quelque chose a configurer pour ca.
Si quelqu'un sait ou a une idee de la raison du probleme cela me serait d'un grand secour.
Avant toute chose, j'ai une question ... Quel est votre chipset IDE ? De plus, ce probleme ne doit pas etre spécifique à Debian, car apres tout, il utilise une base qui est standard sur toutes les distributions (je veux bien entendu parler du noyau Linux).
Cordialement,
Stéphane ACOUNIS
Le Mon, 14 Jul 2003 00:04:05 +0200, Francois-Philippe Il Grande a écrit:
C'est un chipset Intel 815EP. De plus une autre personne avec qui j'en ai discute a deja rencontre exactement le probleme sur une debian et ne l'a pas sur Redhat non plus. Malheureusement nous n'avons pas la solution... Il y a peut-etre quelque chose a configurer dans le kernel pour ca, j'utilise *BSD depuis quelques annees et ne suis pas encore tres familier du kernel Linux. -- Frog
Alors c'est un des nombreux patches non officiel que RedHat utilise. Il faut donc aller récupérer les sources de noyau 2.4.20 sauce RH et décortiquer les changements. Bon courage!
-- Stéphane ACOUNIS
Le Mon, 14 Jul 2003 00:04:05 +0200, Francois-Philippe Il Grande a écrit:
C'est un chipset Intel 815EP.
De plus une autre personne avec qui j'en ai discute a deja rencontre
exactement le probleme sur une debian et ne l'a pas sur Redhat non plus.
Malheureusement nous n'avons pas la solution... Il y a peut-etre quelque
chose a configurer dans le kernel pour ca, j'utilise *BSD depuis
quelques annees et ne suis pas encore tres familier du kernel Linux. --
Frog
Alors c'est un des nombreux patches non officiel que RedHat utilise. Il
faut donc aller récupérer les sources de noyau 2.4.20 sauce RH et
décortiquer les changements.
Bon courage!
Le Mon, 14 Jul 2003 00:04:05 +0200, Francois-Philippe Il Grande a écrit:
C'est un chipset Intel 815EP. De plus une autre personne avec qui j'en ai discute a deja rencontre exactement le probleme sur une debian et ne l'a pas sur Redhat non plus. Malheureusement nous n'avons pas la solution... Il y a peut-etre quelque chose a configurer dans le kernel pour ca, j'utilise *BSD depuis quelques annees et ne suis pas encore tres familier du kernel Linux. -- Frog
Alors c'est un des nombreux patches non officiel que RedHat utilise. Il faut donc aller récupérer les sources de noyau 2.4.20 sauce RH et décortiquer les changements. Bon courage!
-- Stéphane ACOUNIS
J. Mayer
On Mon, 14 Jul 2003 00:30:59 +0200, Thierry PARAGE wrote:
J'ai également constaté la bufférisation des écritures disques ..... Ce qui parfois est gênant dans le genre : ./configure make touch fileref make install find / -newer fileref ..... et dans ce cas un sync et un sleep bien placé suffisent .... Pour quoi faire ?
Le fait que les ecritures soient buffurisees ou non ne changent pas les attributs des fichiers, y compris les attributs de date (derniere modif, dernier access...). Ce serait un bug enorme ! Certaines ecritures peuvent etre differees de plusieurs minutes ! Un "sleep 1" peut servir, car les systemes de fichiers gerent generalement des dates a une seconde pres, mais un sync est une grosse perte de temps et de performances: TOUS les buffers sont synchronises, donc toutes les applis du systeme sont penalisees, et ca ne sert a rien...
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine. Il faut noter que les noyaux recents de la serie 2.4 ont un bug connu qui fait que lorsqu'il y a de gros acces disques, la machine parait bloquee quelques instants (parfois jusqu'a quelques secondes). Le probleme n'a rien a voir avec la synchronisation, et peut arriver lors d'acces au swap, de gros prefetch... Le seul moyen d'y echapper est de prendre le dernier kernel (2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
Cordialement
J. Mayer
On Mon, 14 Jul 2003 00:30:59 +0200, Thierry PARAGE wrote:
J'ai également constaté la bufférisation des écritures disques ..... Ce qui
parfois est gênant dans le genre :
./configure
make
touch fileref
make install
find / -newer fileref .....
et dans ce cas un sync et un sleep bien placé suffisent ....
Pour quoi faire ?
Le fait que les ecritures soient buffurisees ou non ne changent
pas les attributs des fichiers, y compris les attributs de date
(derniere modif, dernier access...). Ce serait un bug enorme !
Certaines ecritures peuvent etre differees de plusieurs minutes !
Un "sleep 1" peut servir, car les systemes de fichiers gerent
generalement des dates a une seconde pres, mais un sync
est une grosse perte de temps et de performances:
TOUS les buffers sont synchronises, donc toutes les applis
du systeme sont penalisees, et ca ne sert a rien...
Les seuls cas ou la bufferisation pose des problemes sont:
- la gestion des devices amovibles
- la gestion de bases de donnees qui necessitent des ecritures
synchronisees pour pouvoir gerer les logs/rollback... de facon
ultra-fiable.
Sinon, la bufferisation est toujours un bienfait,
et un sync doit etre quelque chose de rarissime dans la vie
d'une machine.
Il faut noter que les noyaux recents de la serie 2.4 ont un bug
connu qui fait que lorsqu'il y a de gros acces disques, la machine
parait bloquee quelques instants (parfois jusqu'a quelques secondes).
Le probleme n'a rien a voir avec la synchronisation, et peut
arriver lors d'acces au swap, de gros prefetch...
Le seul moyen d'y echapper est de prendre le dernier kernel
(2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
On Mon, 14 Jul 2003 00:30:59 +0200, Thierry PARAGE wrote:
J'ai également constaté la bufférisation des écritures disques ..... Ce qui parfois est gênant dans le genre : ./configure make touch fileref make install find / -newer fileref ..... et dans ce cas un sync et un sleep bien placé suffisent .... Pour quoi faire ?
Le fait que les ecritures soient buffurisees ou non ne changent pas les attributs des fichiers, y compris les attributs de date (derniere modif, dernier access...). Ce serait un bug enorme ! Certaines ecritures peuvent etre differees de plusieurs minutes ! Un "sleep 1" peut servir, car les systemes de fichiers gerent generalement des dates a une seconde pres, mais un sync est une grosse perte de temps et de performances: TOUS les buffers sont synchronises, donc toutes les applis du systeme sont penalisees, et ca ne sert a rien...
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine. Il faut noter que les noyaux recents de la serie 2.4 ont un bug connu qui fait que lorsqu'il y a de gros acces disques, la machine parait bloquee quelques instants (parfois jusqu'a quelques secondes). Le probleme n'a rien a voir avec la synchronisation, et peut arriver lors d'acces au swap, de gros prefetch... Le seul moyen d'y echapper est de prendre le dernier kernel (2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
Cordialement
J. Mayer
Francois-Philippe Il Grande
On Mon, 14 Jul 2003 00:57:01 +0200 "J. Mayer" wrote:
Le meilleur moyen serait d'ouvrir le fichier avec le flag O_SYNC ou d'utiliser fdatasync regulierement (plutot que fsync).
J'ai essaye aussi, c'est mieux avec fdatasync effectivement mais pas encore parfait.
La vrai solution consiste a compiler un kernel tres recent: le probleme est connu et a ete corrige recement.
On Mon, 14 Jul 2003 00:57:01 +0200 "J. Mayer" wrote:
Le meilleur moyen serait d'ouvrir le fichier avec le flag O_SYNC ou d'utiliser fdatasync regulierement (plutot que fsync).
J'ai essaye aussi, c'est mieux avec fdatasync effectivement mais pas encore parfait.
La vrai solution consiste a compiler un kernel tres recent: le probleme est connu et a ete corrige recement.
Merci pour l'information.
-- Frog
Francois-Philippe Il Grande
On Mon, 14 Jul 2003 00:54:35 +0200 "J. Mayer" wrote:
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video, donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus capturer et perd des images, et quand je fais des fdatasync, je perd les images qui correspondent au moment ou l'appel systeme est effectue.
Il faut noter que les noyaux recents de la serie 2.4 ont un bug connu qui fait que lorsqu'il y a de gros acces disques, la machine parait bloquee quelques instants (parfois jusqu'a quelques secondes). Le probleme n'a rien a voir avec la synchronisation, et peut arriver lors d'acces au swap, de gros prefetch... Le seul moyen d'y echapper est de prendre le dernier kernel (2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
OK, donc c'est bien un bug et pas un probleme de conf. J'utilise un kernel 24.20, mais j'essaierai avec un kernel plus recent, merci.
Les seuls cas ou la bufferisation pose des problemes sont:
- la gestion des devices amovibles
- la gestion de bases de donnees qui necessitent des ecritures
synchronisees pour pouvoir gerer les logs/rollback... de facon
ultra-fiable.
Sinon, la bufferisation est toujours un bienfait,
et un sync doit etre quelque chose de rarissime dans la vie
d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video,
donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus
capturer et perd des images, et quand je fais des fdatasync, je perd les images
qui correspondent au moment ou l'appel systeme est effectue.
Il faut noter que les noyaux recents de la serie 2.4 ont un bug
connu qui fait que lorsqu'il y a de gros acces disques, la machine
parait bloquee quelques instants (parfois jusqu'a quelques secondes).
Le probleme n'a rien a voir avec la synchronisation, et peut
arriver lors d'acces au swap, de gros prefetch...
Le seul moyen d'y echapper est de prendre le dernier kernel
(2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
OK, donc c'est bien un bug et pas un probleme de conf.
J'utilise un kernel 24.20, mais j'essaierai avec un kernel plus
recent, merci.
On Mon, 14 Jul 2003 00:54:35 +0200 "J. Mayer" wrote:
Les seuls cas ou la bufferisation pose des problemes sont: - la gestion des devices amovibles - la gestion de bases de donnees qui necessitent des ecritures synchronisees pour pouvoir gerer les logs/rollback... de facon ultra-fiable. Sinon, la bufferisation est toujours un bienfait, et un sync doit etre quelque chose de rarissime dans la vie d'une machine.
Dans mon cas, je fais de la capture sur un peripherique video, donc quand le systeme arrete tout pour ecrire, mon programme ne peut plus capturer et perd des images, et quand je fais des fdatasync, je perd les images qui correspondent au moment ou l'appel systeme est effectue.
Il faut noter que les noyaux recents de la serie 2.4 ont un bug connu qui fait que lorsqu'il y a de gros acces disques, la machine parait bloquee quelques instants (parfois jusqu'a quelques secondes). Le probleme n'a rien a voir avec la synchronisation, et peut arriver lors d'acces au swap, de gros prefetch... Le seul moyen d'y echapper est de prendre le dernier kernel (2.4.20, je ne suis pas sur, sinon 2.4.21-pre5).
OK, donc c'est bien un bug et pas un probleme de conf. J'utilise un kernel 24.20, mais j'essaierai avec un kernel plus recent, merci.
-- Frog
Francois-Philippe Il Grande
On Mon, 14 Jul 2003 10:40:58 +0200 nicolas wrote:
Le dernier Linux Mag a un article parlant de GNU/Linux en temps réeel. Peut-être qu'il va t'aider ?
L'article dit qu'il faut récupérer des patchs avant de compiler le noyau exprès pour le temps réel.
Interessant, merci pour l'info, je vais m'empresser de l'acheter.
-- Frog
On Mon, 14 Jul 2003 10:40:58 +0200
nicolas <nicolas.patrois@online.fr> wrote:
Le dernier Linux Mag a un article parlant de GNU/Linux en temps réeel.
Peut-être qu'il va t'aider ?
L'article dit qu'il faut récupérer des patchs avant de compiler le noyau
exprès pour le temps réel.
Interessant, merci pour l'info, je vais m'empresser de l'acheter.
