en faisant un petit top ce matin sur ma machine linux, j'ai trouvé ceci :
5 root 9 0 0 0 0 Z 0,0 0.0 0:01 kswapd <defunct>
Dans /var/log/kern.log, j'ai :
Jan 9 09:35:30 vial kernel: kernel BUG at dcache.c:345!
Jan 9 09:35:30 vial kernel: invalid operand: 0000
Jan 9 09:35:30 vial kernel: CPU: 0
Jan 9 09:35:30 vial kernel: EIP: 0010:[prune_dcache+93/328]
Tainted: P
Jan 9 09:35:30 vial kernel: EFLAGS: 00210202
Jan 9 09:35:30 vial kernel: eax: 00000004 ebx: d0088918 ecx:
d0088000 edx
: d0088998
Jan 9 09:35:30 vial kernel: esi: d0088900 edi: d6fba900 ebp:
00002efd esp
: c1595f34
Jan 9 09:35:30 vial kernel: ds: 0018 es: 0018 ss: 0018
Jan 9 09:35:30 vial kernel: Process kswapd (pid: 5, stackpage=c1595000)
Jan 9 09:35:30 vial kernel: Stack: 00000000 c14deae4 00000017 ffffffff
c013fb5b
000033e2 c012948a 00000006
Jan 9 09:35:30 vial kernel: 000001d0 00000020 000001d0 c024a87c
c024a87c
c1594000 000031aa 000001d0
Jan 9 09:35:30 vial kernel: c024a87c c01296e3 c1595fa8 0000003c
000001d0
00000020 c0129750 c1595fa8
Jan 9 09:35:30 vial kernel: Call Trace: [shrink_dcache_memory+27/52]
[shrink
_cache+654/864] [shrink_caches+47/60] [try_to_free_pages_zone+96/224]
[kswapd_ba
lance_pgdat+74/152]
Jan 9 09:35:31 vial kernel: [kswapd_balance+26/48] [kswapd+153/188]
[arch_ker
nel_thread+40/56]
Jan 9 09:35:31 vial kernel:
Jan 9 09:35:31 vial kernel: Code: 0f 0b 59 01 60 2d 21 c0 8d 46 10 8b
48 04 8b
53 f8 89 4a 04
Mon noyau est un 2.4.24 (sur Debian 3.0) , j'ai repris le .config de mon
noyau précédent 2.4.22 avec lequel je n'avais jamais observé de problème.
Je pensais que kswapd gérait le swap, or j'ai testé en allouant pas mal
de mémoire pour faire swapper, tout fonctionne encore normalement.
À quoi sert donc kswapd finalement, peut-on le relancer, ou vivre sans ?
Y a-t-il vraiment un bug dans le kernel ou est-ce un problème physique
(RAM ?)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
no_spam
On Fri, 09 Jan 2004 21:28:41 +0100, Alexandre Vial wrote:
Bonsoir,
en faisant un petit top ce matin sur ma machine linux, j'ai trouvé ceci : 5 root 9 0 0 0 0 Z 0,0 0.0 0:01 kswapd <defunct>
Dans /var/log/kern.log, j'ai :
Jan 9 09:35:30 vial kernel: kernel BUG at dcache.c:345! Jan 9 09:35:30 vial kernel: invalid operand: 0000 Jan 9 09:35:30 vial kernel: CPU: 0 ...
Mon noyau est un 2.4.24 (sur Debian 3.0) , j'ai repris le .config de mon noyau précédent 2.4.22 avec lequel je n'avais jamais observé de problème. Je pensais que kswapd gérait le swap, or j'ai testé en allouant pas mal de mémoire pour faire swapper, tout fonctionne encore normalement. À quoi sert donc kswapd finalement, peut-on le relancer, ou vivre sans ? Y a-t-il vraiment un bug dans le kernel ou est-ce un problème physique (RAM ?)
Oui, c'est un vrai bug kernel.
Tu ne peux pas le relancer, c'est un thread kernel. Tu peux juste rebooter... kswapd réorganise la mémoire en background, indépendement des demandes de mémoire des process. Son but est plus d'optimiser la gestion mémoire. Je ne suis même pas sur qu'il swappe des pages, en fait... Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process). A noter que la mémoire est allouée physiquement lorsqu'on écrit dedans, et pas quand on la mappe. A ce moment là, le kernel libère des pages de façon synchrone et ne se sert donc pas d'un thread pour le faire. Il me semble que kswapd n'est pas indispensable, mais un crash d'un thread kernel pouvant (souvent) masquer un problème plus profond, il est sage de rebooter tant que tu as la main...
On Fri, 09 Jan 2004 21:28:41 +0100, Alexandre Vial wrote:
Bonsoir,
en faisant un petit top ce matin sur ma machine linux, j'ai trouvé ceci :
5 root 9 0 0 0 0 Z 0,0 0.0 0:01 kswapd <defunct>
Dans /var/log/kern.log, j'ai :
Jan 9 09:35:30 vial kernel: kernel BUG at dcache.c:345!
Jan 9 09:35:30 vial kernel: invalid operand: 0000
Jan 9 09:35:30 vial kernel: CPU: 0
...
Mon noyau est un 2.4.24 (sur Debian 3.0) , j'ai repris le .config de mon
noyau précédent 2.4.22 avec lequel je n'avais jamais observé de problème.
Je pensais que kswapd gérait le swap, or j'ai testé en allouant pas mal
de mémoire pour faire swapper, tout fonctionne encore normalement.
À quoi sert donc kswapd finalement, peut-on le relancer, ou vivre sans ?
Y a-t-il vraiment un bug dans le kernel ou est-ce un problème physique
(RAM ?)
Oui, c'est un vrai bug kernel.
Tu ne peux pas le relancer, c'est un thread kernel.
Tu peux juste rebooter...
kswapd réorganise la mémoire en background, indépendement des demandes
de mémoire des process. Son but est plus d'optimiser la gestion
mémoire. Je ne suis même pas sur qu'il swappe des pages, en fait...
Quand tu réclames explicitement de la la mémoire, le kernel
honore toujours ta requête (sauf si tu remplit l'espace de mémoire
virtuelle disponible pour le process). A noter que la mémoire est
allouée physiquement lorsqu'on écrit dedans, et pas quand on la mappe.
A ce moment là, le kernel libère des pages de façon synchrone
et ne se sert donc pas d'un thread pour le faire.
Il me semble que kswapd n'est pas indispensable, mais un crash
d'un thread kernel pouvant (souvent) masquer un problème plus profond,
il est sage de rebooter tant que tu as la main...
On Fri, 09 Jan 2004 21:28:41 +0100, Alexandre Vial wrote:
Bonsoir,
en faisant un petit top ce matin sur ma machine linux, j'ai trouvé ceci : 5 root 9 0 0 0 0 Z 0,0 0.0 0:01 kswapd <defunct>
Dans /var/log/kern.log, j'ai :
Jan 9 09:35:30 vial kernel: kernel BUG at dcache.c:345! Jan 9 09:35:30 vial kernel: invalid operand: 0000 Jan 9 09:35:30 vial kernel: CPU: 0 ...
Mon noyau est un 2.4.24 (sur Debian 3.0) , j'ai repris le .config de mon noyau précédent 2.4.22 avec lequel je n'avais jamais observé de problème. Je pensais que kswapd gérait le swap, or j'ai testé en allouant pas mal de mémoire pour faire swapper, tout fonctionne encore normalement. À quoi sert donc kswapd finalement, peut-on le relancer, ou vivre sans ? Y a-t-il vraiment un bug dans le kernel ou est-ce un problème physique (RAM ?)
Oui, c'est un vrai bug kernel.
Tu ne peux pas le relancer, c'est un thread kernel. Tu peux juste rebooter... kswapd réorganise la mémoire en background, indépendement des demandes de mémoire des process. Son but est plus d'optimiser la gestion mémoire. Je ne suis même pas sur qu'il swappe des pages, en fait... Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process). A noter que la mémoire est allouée physiquement lorsqu'on écrit dedans, et pas quand on la mappe. A ce moment là, le kernel libère des pages de façon synchrone et ne se sert donc pas d'un thread pour le faire. Il me semble que kswapd n'est pas indispensable, mais un crash d'un thread kernel pouvant (souvent) masquer un problème plus profond, il est sage de rebooter tant que tu as la main...
Erwann ABALEA
On Fri, 9 Jan 2004, no_spam wrote:
Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
----- /* Check that a process has enough memory to allocate a * new virtual mapping. */ int vm_enough_memory(long pages) { /* Stupid algorithm to decide if we have enough memory: while * simple, it hopefully works in most obvious cases.. Easy to * fool it, but this should catch most mistakes. */ /* 23/11/98 NJC: Somewhat less stupid version of algorithm, * which tries to do "TheRightThing". Instead of using half of * (buffers+cache), use the minimum values. Allow an extra 2% * of num_physpages for safety margin. */
unsigned long free;
/* Sometimes we want to use more memory than we have. */ if (sysctl_overcommit_memory) return 1;
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory. Il est possible que certaines distributions le font, ce n'est pas le cas sur une Debian.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- D'accord, mais si on se met à utiliser des arguments intelligents dans ce genre de débat, il devient impossible de discuter. Vous sombrez dans la facilité. -+- TS in GNU : La dialectique n'est plus ce qu'elle était.
On Fri, 9 Jan 2004, no_spam wrote:
Quand tu réclames explicitement de la la mémoire, le kernel
honore toujours ta requête (sauf si tu remplit l'espace de mémoire
virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
-----
/* Check that a process has enough memory to allocate a
* new virtual mapping.
*/
int vm_enough_memory(long pages)
{
/* Stupid algorithm to decide if we have enough memory: while
* simple, it hopefully works in most obvious cases.. Easy to
* fool it, but this should catch most mistakes.
*/
/* 23/11/98 NJC: Somewhat less stupid version of algorithm,
* which tries to do "TheRightThing". Instead of using half of
* (buffers+cache), use the minimum values. Allow an extra 2%
* of num_physpages for safety margin.
*/
unsigned long free;
/* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
return 1;
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer
l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en
écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory.
Il est possible que certaines distributions le font, ce n'est pas le cas
sur une Debian.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
D'accord, mais si on se met à utiliser des arguments intelligents dans
ce genre de débat, il devient impossible de discuter.
Vous sombrez dans la facilité.
-+- TS in GNU : La dialectique n'est plus ce qu'elle était.
Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
----- /* Check that a process has enough memory to allocate a * new virtual mapping. */ int vm_enough_memory(long pages) { /* Stupid algorithm to decide if we have enough memory: while * simple, it hopefully works in most obvious cases.. Easy to * fool it, but this should catch most mistakes. */ /* 23/11/98 NJC: Somewhat less stupid version of algorithm, * which tries to do "TheRightThing". Instead of using half of * (buffers+cache), use the minimum values. Allow an extra 2% * of num_physpages for safety margin. */
unsigned long free;
/* Sometimes we want to use more memory than we have. */ if (sysctl_overcommit_memory) return 1;
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory. Il est possible que certaines distributions le font, ce n'est pas le cas sur une Debian.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- D'accord, mais si on se met à utiliser des arguments intelligents dans ce genre de débat, il devient impossible de discuter. Vous sombrez dans la facilité. -+- TS in GNU : La dialectique n'est plus ce qu'elle était.
no_spam
On Sat, 10 Jan 2004 00:55:48 +0100, Erwann ABALEA wrote:
On Fri, 9 Jan 2004, no_spam wrote:
Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
...
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory. Il est possible que certaines distributions le font, ce n'est pas le cas sur une Debian.
Effectivement, il vérifie que l'espace est disponible.J'en avait déduit qu'il marchait toujours comme celà (sans regarder le code, j'avoue), car, comme il prend en compte la taille ram libre + cache + swap pour son calcul, je ne suis jamais arrivé en situation de le faire échouer. Merci pour l'info.
On Sat, 10 Jan 2004 00:55:48 +0100, Erwann ABALEA wrote:
On Fri, 9 Jan 2004, no_spam wrote:
Quand tu réclames explicitement de la la mémoire, le kernel
honore toujours ta requête (sauf si tu remplit l'espace de mémoire
virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
...
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer
l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en
écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory.
Il est possible que certaines distributions le font, ce n'est pas le cas
sur une Debian.
Effectivement, il vérifie que l'espace est disponible.J'en avait déduit
qu'il marchait toujours comme celà (sans regarder le code, j'avoue),
car, comme il prend en compte la taille ram libre + cache + swap
pour son calcul, je ne suis jamais arrivé en situation de le faire
échouer.
Merci pour l'info.
On Sat, 10 Jan 2004 00:55:48 +0100, Erwann ABALEA wrote:
On Fri, 9 Jan 2004, no_spam wrote:
Quand tu réclames explicitement de la la mémoire, le kernel honore toujours ta requête (sauf si tu remplit l'espace de mémoire virtuelle disponible pour le process).
Extrait de mm/mmap.c d'un noyau 2.4.18:
...
Ce que tu décris n'est plus vrai à partir du noyau 2.4.0. On peut activer l'overcommit_memory (ce qui ramène le fonctionnement que tu décris) en écrivant une valeur différente de 0 dans /proc/sys/vm/overcommit_memory. Il est possible que certaines distributions le font, ce n'est pas le cas sur une Debian.
Effectivement, il vérifie que l'espace est disponible.J'en avait déduit qu'il marchait toujours comme celà (sans regarder le code, j'avoue), car, comme il prend en compte la taille ram libre + cache + swap pour son calcul, je ne suis jamais arrivé en situation de le faire échouer. Merci pour l'info.
