tache gourmande

Le Fri, 08 Apr 2005 21:15:43 +0200, Khanh-Dang a écrit:

CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

Il n'y en aurait pas au moins un de trop là ??

Oui, logiquement, il n'y a qu'un ordonnanceur à choisir. Je n'en ai
sélectionné qu'un. J'ai choisi l'ordonnanceur CFQ, puisqu'il est en
général assez bon (j'utilise aussi l'algorthme CFQ pour le QoS).

Je ne sais pas ce qu'il se passe quand plusieurs sont sélectionnés.

En fait, sur mon poste, je me rends compte que je les ai tous (?) :
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

et là, ça ne semble pas poser de problème.

Par contre, je ne parviens pas à trouver ce NOOP dans les menus...

Je n'ai jamais essayé d'en sélectionné plusieurs car je viens juste de
passer au noyau 2.6, mais quelque chose me dit que ça a des chances de
résoudre ton problème.

J'aurais aimé, j'en ai rêvé, mais comme dit, reboot suivant, idem.
Du coup, là, je viens de repasser toutes les options du noyau en revue,
avec ce que j'ai pu y comprendre, je recompile et je reboote quand c'est
fini. Ah oui, j'ai aussi désactivé le PREEMPT pour être sûr que ce
n'est pas ça si j'ai encore le problème.

Merci pour ta participation.

--
Christophe PEREZ
Écrivez moi sans _faute !

[sur un serveur qui rame anormalement pendant une sauvegarde]

top - 12:18:24 up 2 days, 18:38, 2 users, load average: 3.77, 4.59, 3.91
Tasks: 204 total, 9 running, 195 sleeping, 0 stopped, 0 zombie
Cpu(s): 94.0% us, 5.6% sy, 0.3% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 905292k total, 896728k used, 8564k free, 8540k buffers
Swap: 1004052k total, 0k used, 1004052k free, 481428k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21999 root 25 0 8812 7772 352 R 92.0 0.9 21:41.44 bzip2

Il serait peut-être intéressant d'avoir les lignes concernant les 8
autres processus en état running.

Je constate que la charge est assez élevée puisqu'atteignant la valeur
de 4. Essaye de diagnostiquer cette montée en charge trop importante.

On pourrait donner un point en charge pour le processus bzip2, un autre
pour le star qui lit les données, et un dernier point pour celui qui les
écrit. On arrive à un total de 3 (et encore, à supposer que le
processeur compresse aussi vite les données qu'il les lit, ce qui n'est
pas à priori le cas). Tu dépasses largement les 3 en charge.

Pour diagnostiquer, je penserais d'abord à lancer un dd if=/dev/zero
of=fichier_sur_disque1 (sur le système initialement non chargé, i.e.
charge = 0). Lance de même un dd if=/dev/zero of=fichier_sur_disque2, et
aussi pour comparaison un dd if=/dev/zero of=/dev/null. Note à chaque
fois la charge de ton système (qui ne devrait pas dépasser 1.0 à chaque
fois).

Tu peux aussi tester si le système est à genoux ou pas pendant ces
tests.

Est-ce que ça rame encore quand tu effectues ta sauvegarde en balançant
le résultat vers /dev/null au lieu de monfichier.tar.bz2 ?

En gros, essaye d'isoler le problème, pour savoir au niveau de quel
disque il se situe, ou pour savoir si c'est l'association des deux qui
pose problème.

J'ai passé mon serveur d'un ancien PC Céléron 500Mhz, 384Mo de RAM en
une machine neuve Céléron 2.66Ghz, 1Go de RAM, avec un disque SATA.
[et ce nouveau serveur rame anormalement]

Je viens de tomber par hasard sur cette page :
http://kerneltrap.org/node/2450/7217

Il est écrit vers la fin du document qu'il est déconseillé d'activer
l'option CONFIG_HIGHMEM pour les systèmes avec 1 Go de RAM. Pour des
raisons liées au fonctionnement interne de Linux et à l'architecture
x86, l'activation de cette option n'est pas rentable au niveau des
performances quand on a 1 Go de mémoire vive, puisqu'elle ralentit les
I/O.

Le Fri, 08 Apr 2005 23:16:20 +0200, Khanh-Dang a écrit:

[et ce nouveau serveur rame anormalement]

Et bizarrement pas pour tout.
Il semblerait que ce soit ce qui demande identification.
Donc peut-être openldap.
Mais alors, seulement les identifications "distantes" puisque par exemple,
phpldapadmin, sur le même serveur, répond presque normalement au même
moment.

Je viens de tomber par hasard sur cette page :
http://kerneltrap.org/node/2450/7217

Il est écrit vers la fin du document qu'il est déconseillé d'activer
l'option CONFIG_HIGHMEM pour les systèmes avec 1 Go de RAM. Pour des
raisons liées au fonctionnement interne de Linux et à l'architecture
x86, l'activation de cette option n'est pas rentable au niveau des
performances quand on a 1 Go de mémoire vive, puisqu'elle ralentit les
I/O.

Malheureusement, non :
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set


--
Christophe PEREZ
Écrivez moi sans _faute !

Le Fri, 08 Apr 2005 22:46:20 +0200, Khanh-Dang a écrit:

Il serait peut-être intéressant d'avoir les lignes concernant les 8
autres processus en état running.

Déjà, attention, il y a à priori 3 processus pour star si j'ai bien
compris.
Ensuite, il y a énormément de choses qui tournent sur ce serveur, mais
malgré tout, rien de plus que sur le précédent.

De plus, comme dit dans un autre post, ce n'est pas tout qui rame.
Par exemple, proftpd répond relativement vite en anonyme (3-4 secondes
pour un listing), et met un peu plus de temps (10 secondes) en identifié.

[ quoi que non, je viens de retenter le test, et là, je n'arrive même
pas à sortir un "ls" en anonyme", ça semble aléatoire, sauf pour ssh ou
c'est systématique ]

Je constate que la charge est assez élevée puisqu'atteignant la valeur
de 4. Essaye de diagnostiquer cette montée en charge trop importante.

J'aimerais bien. J'ai essayé encore... mais à force de
/etc/init.d/service stop, je ne suis arrivé à rien qui débloque la
situation.
Et comme pour tester à distance, il me faut nécessairement garder
certaines choses (sshd, ldap, nfs etc..), je ne suis pas parvenu à
trouver le truc de trop.

On pourrait donner un point en charge pour le processus bzip2, un autre
pour le star qui lit les données, et un dernier point pour celui qui les
écrit. On arrive à un total de 3 (et encore, à supposer que le
processeur compresse aussi vite les données qu'il les lit, ce qui n'est
pas à priori le cas). Tu dépasses largement les 3 en charge.

Mais c'est sûr qu'ils ne sont pas seuls à tourner sur la machine :
# rc-status
Runlevel: default
local [ started ]
netmount [ started ]
domainname [ started ]
net.eth0 [ started ]
net.eth1 [ started ]
sysklogd [ started ]
vixie-cron [ started ]
sshd [ started ]
gkrellmd [ started ]
lm_sensors [ started ]
portmap [ started ]
slapd [ started ]
dhcp [ started ]
mysql [ started ]
distccd [ started ]
named [ started ]
shorewall [ started ]
et-etpro-ded [ started ]
apache2 [ started ]
xinetd [ started ]
hdparm [ started ]
dovecot [ started ]
icecast [ started ]
ices [ started ]
innd [ started ]
jabber [ started ]
alsasound [ started ]
grenouille [ started ]
teamspeak2-server [ started ]
nfs [ started ]
ntpd [ started ]
upsd [ started ]
upsdrv [ started ]
upsmon [ started ]
postfix [ started ]
proftpd [ started ]
squid [ started ]
spamd [ started ]
samba [ started ]
cupsd [ started ]
bzfs [ started ]
rp-pppoe [ started ]
fetchmail [ started ]
ddclient [ started ]
hotplug [ started ]
coldplug [ started ]

mais je le répète, je compare par rapport au précédent tout vieux
serveur qui fournissait les mêmes services, TiChou peut le confirmer ;-)

Sans ces grosses tâches (compilation, sauvegarde...) qui tournent, voici
ce que me donne top :

top - 18:52:46 up 54 min, 1 user, load average: 0.04, 1.26, 2.14
Tasks: 180 total, 1 running, 179 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.7% us, 0.7% sy, 0.0% ni, 95.4% id, 0.3% wa, 0.0% hi, 2.0% si
Mem: 905224k total, 711828k used, 193396k free, 74656k buffers
Swap: 1004052k total, 0k used, 1004052k free, 323968k cached

Pour diagnostiquer, je penserais d'abord à lancer un dd if=/dev/zero
of=fichier_sur_disque1 (sur le système initialement non chargé, i.e.
charge = 0). Lance de même un dd if=/dev/zero of=fichier_sur_disque2, et
aussi pour comparaison un dd if=/dev/zero of=/dev/null. Note à chaque
fois la charge de ton système (qui ne devrait pas dépasser 1.0 à chaque
fois).

dd if=/dev/zero of=/dev/null

top - 18:53:55 up 55 min, 2 users, load average: 0.36, 1.07, 2.01
Tasks: 183 total, 2 running, 181 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.7% us, 48.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 1.7% si
Mem: 905224k total, 717228k used, 187996k free, 75148k buffers
Swap: 1004052k total, 0k used, 1004052k free, 326348k cached

dd if=/dev/zero of=/autre/test_sur_hdc

top - 18:55:47 up 57 min, 2 users, load average: 0.97, 0.94, 1.85
Tasks: 183 total, 3 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.0% us, 29.0% sy, 0.0% ni, 0.0% id, 59.7% wa, 1.3% hi, 2.0% si
Mem: 905224k total, 895928k used, 9296k free, 2932k buffers
Swap: 1004052k total, 0k used, 1004052k free, 586860k cached

dd if=/dev/zero of=/divers/test_sur_hdd

top - 18:58:03 up 59 min, 2 users, load average: 1.19, 1.03, 1.76
Tasks: 190 total, 2 running, 188 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.2% us, 22.9% sy, 0.2% ni, 0.0% id, 66.4% wa, 1.2% hi, 2.2% si
Mem: 905224k total, 895436k used, 9788k free, 3040k buffers
Swap: 1004052k total, 0k used, 1004052k free, 586640k cached

mais si c'est le load average qu'il faut regarder, c'est difficile puisque
ça évolue en permanence.

Tu peux aussi tester si le système est à genoux ou pas pendant ces
tests.

Non, pas du tout, connexion ssh quasiment normalement.
et :
# time dd if=/dev/zero of=/autre/test_sur_hdc
1177084+0 enregistrements lus.
1177083+0 enregistrements écrits.


real 0m9.714s
user 0m0.940s
sys 0m3.947s

# ls -lh /autre/test_sur_hdc
-rw-r--r-- 1 root root 575M avr 8 19:01 /autre/test_sur_hdc

Est-ce que ça rame encore quand tu effectues ta sauvegarde en balançant
le résultat vers /dev/null au lieu de monfichier.tar.bz2 ?

/usr/bin/star: Can only compress files.

Y veut pô ! ;-)

Cela voudrait dire que ça vient de l'accès disque ?
Parce que pour tester plus facilement, je ne passe plus par la case
backup/star mais par une simple compilation de noyau (make mrpropre puis
make). Malgré tout, le problème reste le même.
Et là, ce n'est pas le même disque (SATA) qui est sollicité, puisque la
sauvegarde se faisant sur un IDE.

En gros, essaye d'isoler le problème, pour savoir au niveau de quel
disque il se situe, ou pour savoir si c'est l'association des deux qui
pose problème.

J'essaye, j'essaye...

Merci pour le mal que tu te donnes.

--
Christophe PEREZ
Écrivez moi sans _faute !

On Fri, 08 Apr 2005 14:14:08 -0400, Christophe PEREZ wrote:

Le Fri, 08 Apr 2005 12:34:40 -0400, Christophe PEREZ a écrit:

mais si ça l'est, le résultat est tout à fait normal. Essaye de
vérifier avec chrt ou taskset (du package sys-process/schedutils)

Je vais essayer ça.

Bon, j'ai recompilé mon noyau avec seulement :
# grep IOSCHED /usr/src/linux/.config
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set

Ca semble pas mal.

et

# grep PREEMPT /usr/src/linux/.config
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_BKL is not set
# CONFIG_DEBUG_PREEMPT is not set

Ca aussi...

Rebooté, et même problème.

Je n'ai pas encore vraiment étudier les outils schedutils, mais voici
déjà ce que j'ai pu avoir :

# ps axf | grep 'star '
14924 pts/2 S+ 0:00 | _ sh -c /usr/bin/star -c -bz artype=exustar -xdev -acl -xattr -link-dirs -sparse ???errctl=/usr/local/perso/backup/star_errctl ???-fifo fsdm -no-statistics -silent ???-dump -newer=/usr/local/perso/backup/serveur1-www.stamp ???-not pat=lost+found{%!/*} C=/var /var/www ???> /autre/sauvegarde/Linux/serveur1-www-day-5.tar.bz2
14925 pts/2 SL+ 0:00 | _ /usr/bin/star -c -bz artype=exustar -xdev -acl -xattr -link-dirs -sparse errctl=/usr/local/perso/backup/star_errctl -fifo fsdm -no-statistics -silent -dump -newer=/usr/local/perso/backup/serveur1-www.stamp -not pat=lost+found{%!/*} C=/var /var/www
14927 pts/2 S+ 0:00 | _ /usr/bin/star -c -bz artype=exustar -xdev -acl -xattr -link-dirs -sparse errctl=/usr/local/perso/backup/star_errctl -fifo fsdm -no-statistics -silent -dump -newer=/usr/local/perso/backup/serveur1-www.stamp -not pat=lost+found{%!/*} C=/var /var/www

# chrt -m -p 14925
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0
# chrt -m -p 14927
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0
# chrt -m -p 14924
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0

Et sans les -m ?

L'erreur est-elle là ?
Ce mini à 99 ça me fait bizarre quand même.

C'est fort possible:
si je fait un chrt -p sur le shell dans lequel je suis, j'obtiens:

chrt -p 3666
pid 3666's current scheduling policy: SCHED_OTHER

pid 3666's current scheduling priority: 0
et

chrt -m -p 3666
SCHED_FIFO min/max priority : 1/99

SCHED_RR min/max priority : 1/99
SCHED_OTHER min/max priority : 0/0

Essaye sans le '-m' pour voir sur quel scheduler il tourne.
S'il est sur le round-robin ou la FIFO, ton problème vient très
certainement de là: les process schédulés dans ces modes là sont
toujours prioritaires par rapport aux process schédulés en 'OTHER'.

Le Sat, 09 Apr 2005 01:27:55 +0200, l'indien a écrit:

# grep IOSCHED /usr/src/linux/.config
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set

Ca semble pas mal.

entre temps, pour essayer, j'avais activer CFQ seul, mais sans plus de
résultat.

# grep PREEMPT /usr/src/linux/.config
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_BKL is not set
# CONFIG_DEBUG_PREEMPT is not set

Ca aussi...

Ok, et je met le :
CONFIG_PREEMPT_BKL
ou pas ?

[...]

# chrt -m -p 14924
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0

Et sans les -m ?

pas encore essayé, mais...

Ce mini à 99 ça me fait bizarre quand même.

C'est fort possible:
si je fait un chrt -p sur le shell dans lequel je suis, j'obtiens:

chrt -p 3666
pid 3666's current scheduling policy: SCHED_OTHER

pid 3666's current scheduling priority: 0

Ah !
# echo $$
7969
# chrt -p 7969
pid 7969's current scheduling policy: SCHED_OTHER
pid 7969's current scheduling priority: 0

et

chrt -m -p 3666
SCHED_FIFO min/max priority : 1/99

SCHED_RR min/max priority : 1/99
SCHED_OTHER min/max priority : 0/0

# chrt -m -p 7969
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0

ça me semble complètement différent.

Essaye sans le '-m' pour voir sur quel scheduler il tourne.
S'il est sur le round-robin ou la FIFO, ton problème vient très
certainement de là:

Il me semble aussi oui.
J'ai le sentiment que je (tu) ne dois pas être loin du but et ça me
redonne espoir.

les process schédulés dans ces modes là sont
toujours prioritaires par rapport aux process schédulés en 'OTHER'.

Et il faudrait jouer sur quoi pour y changer quelque chose ?
Moi ce que j'y comprends, c'est que je suis bien sur OTHER, mais avec un
mini de 99. Du coup, j'en déduis que c'est systématiquement prioritaire.
Ce doit bien être une option du noyau, mais laquelle ?

Voici mon config actuel que j'ai beaucoup allégé selon ce que je
pensais pouvoir supprimer sans problème, si ça peut aider à m'aider :
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_APM=m
CONFIG_APM_RTC_IS_GMT=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG_PCI=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM_COUNT
CONFIG_INITRAMFS_SOURCE=""
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_CFQ=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_QLA2XXX=y
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_TCPDIAG=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
CONFIG_NE2K_PCI=m
CONFIG_VIA_RHINE=m
CONFIG_R8169=y
CONFIG_PPP=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X24
CONFIG_INPUT_MOUSEDEV_SCREEN_Yv8
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT%6
CONFIG_PRINTER=m
CONFIG_RTC=y
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISA=m
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_EEPROM=m
CONFIG_VIDEO_DEV=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SPEAKUP_DEFAULT="none"
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_INTEL8X0=m
CONFIG_USB=m
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_QUOTA=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_SQUASHFS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_DES=y
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

--
Christophe PEREZ
Écrivez moi sans _faute !

Le Fri, 08 Apr 2005 22:44:53 -0400, Christophe PEREZ a écrit:

# chrt -m -p 14924
SCHED_FIFO min/max priority : 99/99
SCHED_RR min/max priority : 99/99
SCHED_OTHER min/max priority : 0/0

Et sans les -m ?

pas encore essayé

Essayé et ça me donne comme pour tout :
current scheduling policy: SCHED_OTHER
current scheduling priority: 0


..searching...

--
Christophe PEREZ
Écrivez moi sans _faute !