Léa-Linux & amis :   LinuxFR   GCU-Squad   GNU
Aller à la page:  Page précédente 1 2 3 4 Page suivante
Page: 2 sur 4
Re: Temps noyau intempestifs lors d'IO
Envoyé par: panthere noire

mhmm déjà si tu prouvai donner les détail de ta config matériel. +ta distrib + gnome ou kde autre ?

Ensuite que donne un cat /boot/config-`uname -r` |grep 1000 et uname -a et colle aussi un ps aux


net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3

Poste le Monday 14 July 2008 15:02:33
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Mes problèmes sont indépendant du matos, car il sont commun à toute les config (du p3 500MHz que j'ai tester, au AMD Phenom et au Core2duo), et aussi sur toute les distro de moins d'un ans (gentoo netinstall, debian, suse, redhat, ...), j'ai meme tester les version non stable de xorg, et kde4, meme résultat. J'ai aussi tester sur fluxbox, sur kde4, sur ces 2 environnement je n'avais presque rien de lancer.

Mon mon pc principal sont les quel je fait les testes avant de les confirmer sur des autres pc:
AMD X2 BE-2400 @ 2.3Ghz en ondemand soit 1GHz en idle
Gentoo netinstall elle doit dater de 1 mois sur architecture amd64.
Kde 3.5 (Qt 4.3.3)
gentoo-sources fait main

Je pense que tu veux ça:
# CONFIG_HZ_1000 is not set
CONFIG_BLK_DEV_RZ1000=m
CONFIG_PATA_RZ1000=m
# CONFIG_NET_SB1000 is not set
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_NETDEV_10000 is not set

Ca:
Linux bureau 2.6.25-gentoo-r6 #1 SMP Thu Mar 13 07:36:11 CET 2008 x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2400 AuthenticAMD GNU/Linux

Et le ps aux, tout les pc on été nettoyé coté service, et sont trés différent:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0    804   316 ?        Ss   Jul13   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S<   Jul13   0:00 [migration/0]
root         4  0.0  0.0      0     0 ?        S<   Jul13   0:00 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Jul13   0:00 [migration/1]
root         6  0.0  0.0      0     0 ?        S<   Jul13   0:01 [ksoftirqd/1]
root         7  0.0  0.0      0     0 ?        S<   Jul13   0:00 [events/0]
root         8  0.0  0.0      0     0 ?        S<   Jul13   0:00 [events/1]
root         9  0.0  0.0      0     0 ?        S<   Jul13   0:00 [khelper]
root        71  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kblockd/0]
root        72  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kblockd/1]
root        76  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kacpid]
root        77  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kacpi_notify]
root       187  0.0  0.0      0     0 ?        S<   Jul13   0:00 [ksuspend_usbd]
root       193  0.0  0.0      0     0 ?        S<   Jul13   0:00 [khubd]
root       196  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kseriod]
root       216  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kondemand/0]
root       217  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kondemand/1]
root       245  0.0  0.0      0     0 ?        S    Jul13   0:00 [pdflush]
root       246  0.0  0.0      0     0 ?        S    Jul13   0:01 [pdflush]
root       247  0.0  0.0      0     0 ?        S<   Jul13   0:01 [kswapd0]
root       248  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aio/0]
root       249  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aio/1]
root       250  0.0  0.0      0     0 ?        S<   Jul13   0:00 [cifsoplockd]
root       251  0.0  0.0      0     0 ?        S<   Jul13   0:00 [cifsdnotifyd]
root       253  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aufsd]
root       254  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aufsd]
root       255  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aufsd]
root       256  0.0  0.0      0     0 ?        S<   Jul13   0:00 [aufsd]
root       427  0.0  0.0      0     0 ?        S<   Jul13   0:00 [kpsmoused]
root       489  0.0  0.0      0     0 ?        S<   Jul13   0:00 [rpciod/0]
root       490  0.0  0.0      0     0 ?        S<   Jul13   0:11 [rpciod/1]
root       491  0.0  0.0      0     0 ?        S<   Jul13   0:00 [krxrpcd/0]
root       492  0.0  0.0      0     0 ?        S<   Jul13   0:00 [krxrpcd/1]
bin       1130  0.0  0.0   3696   392 ?        Ss   Jul13   0:00 /sbin/portmap
root      1132  0.0  0.0   3720   620 ?        Ss   Jul13   0:00 /sbin/rpc.statd
root      1136  0.0  0.0      0     0 ?        S    Jul13   0:00 [lockd]
root      1237  0.0  0.0  12824  1288 ?        S<s  Jul13   0:00 /sbin/udevd --daemon
root      2208  0.0  0.0      0     0 ?        S<   Jul13   0:00 [ata/0]
root      2209  0.0  0.0      0     0 ?        S<   Jul13   0:00 [ata/1]
root      2210  0.0  0.0      0     0 ?        S<   Jul13   0:00 [ata_aux]
root      2239  0.0  0.0      0     0 ?        S<   Jul13   0:00 [scsi_eh_0]
root      2240  0.0  0.0      0     0 ?        S<   Jul13   0:00 [scsi_eh_1]
root      2243  0.0  0.0      0     0 ?        S<   Jul13   0:00 [scsi_eh_2]
root      2244  0.0  0.0      0     0 ?        S<   Jul13   0:00 [scsi_eh_3]
101       3395  0.0  0.0  14676   936 ?        Ss   Jul13   0:00 /usr/bin/dbus-daemon --system
root      3579  0.0  0.0  19612   652 ?        Ss   Jul13   0:00 /usr/kde/3.5/bin/kdm
root      3613  2.0  4.7 940744 97020 tty7     SLs+ Jul13  42:45 /usr/bin/X -br -nolisten tcp +extension DOUBLE-BUFFER -br -nolisten tcp +extension DOUBLE-BUFFER :0 vt7 -auth /var/run/xauth/A:0-sIAYMm
root      3734  0.0  0.0  28016  1060 ?        S    Jul13   0:00 -:0
root      4539  0.0  0.0   6356   404 ?        Ss   Jul13   0:01 /usr/sbin/gpm -m /dev/input/mice -t ps2
102       4583  0.0  0.1  25912  3196 ?        Ss   Jul13   0:00 /usr/sbin/hald --use-syslog --verbose=no
root      4611  0.0  0.0  15484  1116 ?        S    Jul13   0:00 hald-runner
root      4735  0.0  0.1  19812  3940 ?        Ss   Jul13   0:15 /bin/bash /usr/sbin/fancontrol /etc/fancontrol
102       4922  0.0  0.0  16496   948 ?        S    Jul13   0:00 hald-addon-keyboard: listening on /dev/input/event0
102       4923  0.0  0.0  16496   952 ?        S    Jul13   0:00 hald-addon-keyboard: listening on /dev/input/event1
102       4924  0.0  0.0  16496   952 ?        R    Jul13   0:00 hald-addon-keyboard: listening on /dev/input/event2
root      4926  0.0  0.0  17596  1140 ?        S    Jul13   0:00 /usr/libexec/hald-addon-cpufreq
102       4927  0.0  0.0  16496   944 ?        S    Jul13   0:00 hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event
nobody    4980  0.0  0.0  10004   836 ?        Ss   Jul13   0:00 /sbin/rpc.statd --no-notify
root      4981  0.0  0.0  16356   536 ?        Ss   Jul13   0:00 /usr/sbin/rpc.idmapd
root      5004  0.0  0.0      0     0 ?        S<   Jul13   0:13 [cifsd]
user      5015  0.0  0.0   9232  1344 ?        Ss   Jul13   0:00 /bin/sh /usr/kde/3.5/bin/startkde
distcc    5028  0.0  0.0  14624   288 ?        SNs  Jul13   0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16
distcc    5029  0.0  0.0  14624   240 ?        SN   Jul13   0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16
distcc    5039  0.0  0.0  14624   240 ?        SN   Jul13   0:00 /usr/bin/distccd --pid-file /var/run/distccd/distccd.pid -N 19 --user distcc --user distcc --jobs 2 --port 3632 --log-level warning --allow 192.168.0.0/16
root      5077  0.0  0.0   1436   152 ?        S    Jul13   0:00 /opt/vmware/workstation/bin/vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth0
user      5131  0.0  0.0  25668   720 ?        S    Jul13   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session
user      5132  0.0  0.0  14676   844 ?        Ss   Jul13   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root      5151  0.0  0.0   3556   152 ?        S    Jul13   0:00 start_kdeinit --new-startup +kcminit_startup
user      5152  0.0  0.3 110108  7260 ?        Ss   Jul13   0:02 kdeinit Running...
user      5155  0.0  0.1 111972  3732 ?        S    Jul13   0:08 dcopserver [kdeinit] --nosid
user      5157  0.0  0.3 115900  7272 ?        S    Jul13   0:02 klauncher [kdeinit] --new-startup
user      5159  0.0  1.1 257472 23820 ?        S    Jul13   0:40 kded [kdeinit] --new-startup
user      5164  0.0  0.0   3692   400 ?        S    Jul13   0:00 kwrapper ksmserver
user      5166  0.0  0.4 124504  9604 ?        S    Jul13   0:00 ksmserver [kdeinit]
user      5167  0.0  0.6 133072 13672 ?        S    Jul13   0:27 kwin [kdeinit] -session 10c3ea7265000121000894800000052800000_1217
user      5169  0.0  1.2 186580 24752 ?        S    Jul13   0:30 kdesktop [kdeinit]
user      5171  0.0  1.0 165344 22152 ?        S    Jul13   1:32 kicker [kdeinit]
user      5173  0.0  0.0  21724  1620 ?        S    Jul13   0:08 ksysguardd
user      5179  2.3  0.5  78680 11052 ?        RL   Jul13  48:18 /usr/kde/3.5/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -c drkonqi -l 3 -f
user      5181  0.0  0.4 126496  8936 ?        S    Jul13   0:01 kaccess [kdeinit]
user      5184  0.0  0.6 134768 14184 ?        S    Jul13   0:00 kmix [kdeinit] -session 10c3ea7265000119419980400000054730008_1217
user      5185  0.0  0.7 107744 15684 ?        S    Jul13   1:42 knetstats -session 10c3ea7265000120569970300000059360061_1217409072_317095
user      5187  0.0  0.6 112408 12392 ?        S    Jul13   0:25 ksensors -session 10c3ea7265000121000901500000052800011_1217409072_316780
user      5191  0.0  1.5 181048 31652 ?        S    Jul13   0:15 akregator -session 10c3ea7265000121343912700000055620893_1217409072_316766
user      5194  0.0  0.5 171552 12080 ?        S    Jul13   0:02 knotify [kdeinit]
user      5195  0.0  0.9 209936 19756 ?        S    Jul13   0:01 kalarm -session 10c3ea7265000121394700500000052680009_1217409072_316909
user      5206  0.0  0.3 126444  8228 ?        S    Jul13   0:01 kalarmd --autostart
user      5209  0.0  0.5 138944 11700 ?        S    Jul13   0:00 kpowersave [kdeinit]
user      5211  0.0  0.5 128956 11636 ?        S    Jul13   0:05 klipper [kdeinit]
root      5244  0.0  0.0   5800   692 tty1     Ss+  Jul13   0:00 /sbin/agetty 38400 tty1 linux
root      5245  0.0  0.0   5800   692 tty2     Ss+  Jul13   0:00 /sbin/agetty 38400 tty2 linux
root      5246  0.0  0.0   5800   696 tty3     Ss+  Jul13   0:00 /sbin/agetty 38400 tty3 linux
root      5247  0.0  0.0   5800   700 tty4     Ss+  Jul13   0:00 /sbin/agetty 38400 tty4 linux
root      5248  0.0  0.0   5800   700 tty5     Ss+  Jul13   0:00 /sbin/agetty 38400 tty5 linux
root      5249  0.0  0.0   5800   692 tty6     Ss+  Jul13   0:00 /sbin/agetty 38400 tty6 linux
user      5274  0.8  1.2 145880 26720 ?        S    Jul13  17:20 konsole [kdeinit] -caption=ssh amber -icon konsole -miniicon konso
user      5275  0.0  0.1  17464  2076 pts/1    Ss+  Jul13   0:37 ssh root@192.168.0.10
user      8334  0.0  0.1  90804  2620 ?        S    Jul13   0:00 /usr/kde/3.5/bin/kdesud
user      8354  0.0  0.6 128880 12488 ?        S    Jul13   0:03 kio_uiserver [kdeinit]
user      8858  0.0  2.6 306076 54788 ?        S    Jul13   0:45 kopete -caption Kopete -icon kopete -miniicon kopete
user     19237  0.0  0.0   1664   244 ?        Ss   12:26   0:00 ssh-agent
user     19258  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19265  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19271  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19277  0.0  0.0   1664   244 ?        Ss   12:29   0:00 ssh-agent
user     19307  0.0  0.0   1664   244 ?        Ss   12:31   0:00 ssh-agent
user     19312  0.0  0.0   1664   244 ?        Ss   12:31   0:00 ssh-agent
user     19318  0.0  0.0   1664   248 ?        Ss   12:32   0:00 ssh-agent
user     19380  0.0  0.0   1664   244 ?        Ss   12:39   0:00 ssh-agent
user     19385  0.0  0.0   1664   244 ?        Ss   12:39   0:00 ssh-agent
root     21043  0.0  0.4  76892  9056 ?        S    15:05   0:00 /usr/kde/3.5/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -l 3 -f
user     24989  1.3  1.2 144612 25356 ?        R    20:20   1:33 konsole [kdeinit] -caption=ssh amber -icon konsole -miniicon konso
user     24990  0.3  0.0  17492  2036 pts/4    Ss+  20:20   0:23 ssh root@192.168.0.10
user     25752  0.1  1.3 185268 26892 ?        S    21:54   0:02 konqueror [kdeinit] -mimetype inode/directory file:///mnt/
user     25846  0.0  0.4 117000  9944 ?        S    22:00   0:00 kdialogd3
user     25917  5.5  2.7 536676 56584 ?        Sl   22:04   0:29 kaffeine /mnt/disk2/clip/clip/Zaho - Cest Chelou MC4.mpg
user     25919  0.0  0.2 113592  5940 ?        S    22:04   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     25934  0.0  0.0   9200  1280 ?        S    22:05   0:00 /bin/bash /usr/local/bin/firefox
user     25942  0.0  0.0   8940  1256 ?        S    22:05   0:00 /bin/bash /usr/bin/kgtk2-wrapper /usr/bin/firefox
user     25944  0.0  0.1  87112  3180 ?        S    22:05   0:00 /bin/bash /usr/libexec/mozilla-launcher
user     25953  4.0  4.0 490968 84312 ?        Sl   22:05   0:19 /usr/lib64/mozilla-firefox/firefox-bin
user     25986  0.0  0.0   9364  1528 ?        S    22:05   0:00 /bin/bash /usr/libexec/mozilla-launcher
user     25996  0.8  2.3 443288 49044 ?        Sl   22:05   0:04 /usr/lib64/mozilla-thunderbird/thunderbird-bin
user     26062  0.0  0.0  17744  1836 pts/2    Ss   22:11   0:00 /bin/bash
root     26067  0.0  0.0  17484  1896 pts/2    S    22:11   0:00 bash
user     26087  0.0  0.2 113592  5932 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     26088  0.0  0.2 113592  5932 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     26089  0.0  0.2 113592  5940 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
root     26093  0.0  0.0    776   220 ?        S    22:13   0:00 sleep 10
root     26094  0.0  0.0  14616   952 pts/2    R+   22:13   0:00 ps aux

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Monday 14 July 2008 22:14:59
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: panthere noire

Déja je précise que je ne connait pas geento.
A première vue tu plusieurs foit les même truc lancer:
par exemple:
user     19237  0.0  0.0   1664   244 ?        Ss   12:26   0:00 ssh-agent
user     19258  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19265  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19271  0.0  0.0   1664   244 ?        Ss   12:28   0:00 ssh-agent
user     19277  0.0  0.0   1664   244 ?        Ss   12:29   0:00 ssh-agent
user     19307  0.0  0.0   1664   244 ?        Ss   12:31   0:00 ssh-agent
user     19312  0.0  0.0   1664   244 ?        Ss   12:31   0:00 ssh-agent
user     19318  0.0  0.0   1664   248 ?        Ss   12:32   0:00 ssh-agent
user     19380  0.0  0.0   1664   244 ?        Ss   12:39   0:00 ssh-agent
user     19385  0.0  0.0   1664   244 ?        Ss   12:39   0:00 ssh-agent

user     26087  0.0  0.2 113592  5932 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     26088  0.0  0.2 113592  5932 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     26089  0.0  0.2 113592  5940 ?        S    22:12   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so
user     25919  0.0  0.2 113592  5940 ?        S    22:04   0:00 kio_file [kdeinit] file /tmp/ksocket-user/klauncherorBpUb.slave-so

pareil pour firefox

Le simple faite de lancer plusieurs foit les applications va manger plus de ressources. As-tu essayer de faire tes test en simple user ?
car un linux charger aux minimum sa tape dans les 5-8 M , de no jour environ 32-40M sans x mai bon.

Apparemment tu lit tes video sur un support annexe, sa aussi sa manges des ressources si tu veux une lecture sans problème tu peux la copier en ram si tu en as suffisamment. ensuite si tu as compiler tes logiciel a la main, es-tu sure d'avoir passer les bon paramètre a gcc.

ensuite il faut comprendre une chose, linux c'est du vrai multitache.

pour schématiser en gros. windows va executer un bloc d'instruction qui peux contenir plusieurs instruction, sous linux sa sera chaqu'un son tour.
ce qui revient a dire que si dans le bloc d'instruction sa plante, sa te gèle le pc ou sa te le redémarre ect. Sous linux c'est donc peux probable que sa arrive.
Ensuite un kernel 2.6.25 a pas mal d'option que tu ne doit pas utiliser genre la gestion des ressourcer par utilisateur/groupe
je doute aussi que sos windows tu est garder un par feux. donc sous linux il te faudrait supprimer netfilter,iptables du noyaux a tes risque et perile hein. donc de ce coter la il te faux encore creuser smiling smiley
tu peux aussi avoir un module charger en dure qui gène la bonne exécution des reste des application genre l'usb qui a une priorité élevée.

Enfin linux offre aussi plus de possibilité que windows donc c'est aussi logique que si tu garde tout ben que sa soie un peux lourd, car la je peux te dire que c'est pas optimiser du tout et malgré ce que tu dit kde/gnome son a proscrire car très lourd. par exemple kde pré-charge les lib et permet meme de prechager une instance (ou plus) de konqueror ect. bref tu pas commit forcement les même fautes sur chaque machine mai sa peux suffire a ce que sa coince.

enfin linux exécute une application sur 1 core et pas forcement sur les 2. Moi je permet, pour la compilation du noyaux de faire sa sure les 2 smiling smiley

Mai bon comme je connait pas gento je ne peux pas le garentire.








net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3

Poste le Tuesday 15 July 2008 00:46:36
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Comme préciser plus haut j'ai fait les testes sur des config très différente avec le même résulta, avec une fluxbox et 46 processus de lancer (et aucun en double, j'avais regarder par ps aux) même probléme.

Sous windows on peu lancer plusieurs applications sans aucune différence tant qu'on assez de ram, idem sous linux apparemment.
Je croi que kaffeine met en cache un peu à l'avance les fichier video.

Pour gcc:
CFLAGS="-O2 -pipe -march=k8 -msse3"
Que du safe car il me faut un pc très stable.

Group CPU Shuduler activé mais je fait rien pour le gérer je laisse linux faire si il le fait.
Sous windows j'avais garder un par feu, j'ai plus windows chez moi sauf en pc virtuel (depuis 2 jours).
J'ai désativé le parefeu sous presque tout mes distro, (netfilter dans le noyau et iptables).
J'ai mit en dur que ce qui me sert et j'ai pas toucher au priorité (cf windows marche trés bien en desktop si on gére pas le priorité)

Je répéte, j'ai tester avec kde3.5, kde4, gnome, fluxbox et en console pur.
J'utilise qu'un seul coeur en général sauf pour les compilations.

J'ai pris que windows xp mais par contre j'ai tester différente distribution de linux, avec des gammes de logiciels divers (j'ai fait des testes sur des serveurs, que le IO car pas d'interface, sur des desktop léger, twm + xterm, flux, sur des desktop lourd kde3.5, kde4, gnome).

Cette linux gérer plus de truc mais les gères mieux, ça ce vois car sur les application n'utilisant que cpu et ram j'ai un gain comparer à windows.
Et ce n'est pas un probléme de lenteur car si non ce serai d'un ralentissement général que je me plaindrai, ici le probléme c'est que les IO prenne du temps cpu (réellement) et pas sous windows (me dite pas que c'est parce qu'on voit rien, teste à l'appui en début de topic, hardware, et pas de ralentissement de bench cpu en priorité faible contrairement à linux).
Et faire rammer un lecteur video en fessant défiler la scrollbar de sont navigateur c'est limite, et idem pour l'affichage de longue liste de texte comme dans mon application, c'est temps réel sous windows et sous linux ça rame...

Je suis pas la pour blamer linux, je suis la pour faire en sorte de trouver une solution

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Tuesday 15 July 2008 10:05:41
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: panthere noire

Citation
alpha_one_x86
Pour gcc:
CFLAGS="-O2 -pipe -march=k8 -msse3"
Que du safe car il me faut un pc très stable.

j'ai pas installer le man de gcc donc je peux pas te dire si c est sufisant.
Citation

Group CPU Shuduler activé mais je fait rien pour
le gérer je laisse linux faire si il le fait.
Sous windows j'avais garder un par feu, j'ai plus
windows chez moi sauf en pc virtuel (depuis 2
jours).
J'ai désativé le parefeu sous presque tout mes
distro, (netfilter dans le noyau et iptables).
J'ai mit en dur que ce qui me sert et j'ai pas
toucher au priorité (cf windows marche trés bien
en desktop si on gére pas le priorité)

Je répéte, j'ai tester avec kde3.5, kde4, gnome,
fluxbox et en console pur.
J'utilise qu'un seul coeur en général sauf pour
les compilations.

tu veux dire les 2 coeur en 1 seul ou 1 séparement ??
Citation

Et ce n'est pas un probléme de lenteur car si non
ce serai d'un ralentissement général que je me
plaindrai, ici le probléme c'est que les IO prenne
du temps cpu (réellement) et pas sous windows (me
dite pas que c'est parce qu'on voit rien, teste à
l'appui en début de topic, hardware, et pas de
ralentissement de bench cpu en priorité faible
contrairement à linux).
certe.
Citation

Et faire rammer un lecteur video en fessant
défiler la scrollbar de sont navigateur c'est
limite, et idem pour l'affichage de longue liste
de texte comme dans mon application, c'est temps
réel sous windows et sous linux ça rame...

ce que tu dit la c'est typique d'une carte video qui n'a pas les driver proprio ou encore que c est mal configurer. enfin si ta video c est du flash ben sa pue et sa marche pas toujours très bien. donc rien a voir avec les i/o

si c est un video :
Pour cree un lecteur virtuel de 200 mg adapte sa a ta video et place y le fichier.
mount -t tmpfs -o size=200m,nr_inodes=10k,mode=0700 tmpfs /dd_virtuel

Citation

Je suis pas la pour blamer linux, je suis la pour
faire en sorte de trouver une solution
Besoin d'aide:
pas de problème ou presque :-D

comme on ne c'est pas exactement ce que tu as tester et ou sa te gène on peux difficilement t'aider, hormis le fait que sa mange du cpu. ceci dit la charge est de combien sans comparer avec windows et qu'elle son les valeurs et ou prend tu les mesure. ?

net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3

Poste le Tuesday 15 July 2008 11:26:18
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: panthere noire

erf laisse tomber la denière phrase je suis planter avec le copier coller.
comme on ne c'est pas exactement ce que tu as tester et ou sa te gène on peux difficilement t'aider, hormis le fait que sa mange du cpu. ceci dit la charge est de combien sans comparer avec windows et qu'elle son les valeurs et ou prend tu les mesure. ?

on peux pas éditer les poste ici c'est pénible :-(

net install--> sid2.6.32 dist i386
fluxbox
nvidia 8800gtx 768 ddr3

Poste le Tuesday 15 July 2008 11:39:26
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: diancech

Pour les CFLAGS a priori pas de soucis (à moins que k8 ne soit pas la bonne arch mais je pense que c'est bon ;-) ).

Pour le problème de vidéo qui saute effectivement, cela peux venir d'un soucis de configuration de X (à vérifier qu'il n'y a rien de louche dans /var/log/Xorg.0.log), moi j'ai effectivement un soucis vidéo, pas quand je joue avec l'ascenseur d'une fenêtre mais quand je déplace un xterm par exemple (cela fait sauter la vidéo), par contre cela ne fait ça qu'avec mplayer, je ne me suis pas pencher sur ce soucis étant donné que j'utilise VLC la plupart du temps et je n'ai pas ce soucis avec ce dernier.

--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius

Poste le Tuesday 15 July 2008 13:11:09
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: AlSim

Citation
alpha_one_x86
Je suis pas la pour blamer linux, je suis la pour faire en sorte de trouver une solution
Pas l'endroit idéal pour ce genre de problème... [www.kernel.org]

[catwell.info]

Poste le Tuesday 15 July 2008 14:41:58
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Je commence à me répété, cf début de post, mesure physique de l'utilisation du cpu et logiciel, et les mesures s'accorde.

Non, X est bien config, j'ai tester différente option, mais j'ai bien les drivers proprio, et il marche bien:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8600 GT/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 169.09
...
Et si no je pourrai pas jouer à Quake4, doom3, ut2004, et d'autre jeux sous wine ou en natif à fond (3360x1500 en AA4).

Lecture de video sous ram disk: ok, juste les temps cpu de décompression mais c'est pas gênant et c'est normal.
J'ai tester avec le défilement d'une page web sous firefox, et avec mplayer et kaffeine. Si vlc à trouvé le moyen de désyncroniser sont affichage pour pas que les éléments graphique font ramer ces élément graphique telque ça video, il faut l'appliquer en masse en l'intégrant dans X11 pour qu'aucun éléments puisse en faire ramer un autre.
Aprés je sais pas ce que vous en penser, mais techniquement les problèmes exposer içi sont les seul défaut qui me gène sous linux. Et c'est les seul truc qui fait que windows n'est pas complément écraser par linux.


Donc pour résumer avec X11 (sous Qt, gtk, ou autre) les items ne sont pas indépendant et peuvent ce faire ramer mutuellement, l'affichage n'est pas temps réel et ce resent surtout lors de nombreux éléments.
Les IO (réseau ou hdd) sous linux prenne du temps cpu qui ne peu pas être utilisé par des applications. Sous windows ce n'est pas le cas teste à l'appui.

Ca ne sert à rien de regarder coté matos et drivers car j'ai tester cela sur plein de config/distrib différente avec le même résultat, je parle de l'interface que quand le pc à une prise en charge complète de la carte graphique.
Je m'assure toujours pour toute ce que j'ai dit que les testes ce fond dans les bonne condition, drivers et matos 100% reconnu et pris en charge.

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Tuesday 15 July 2008 15:01:58
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Citation
AlSim
alpha_one_x86 a écrit :Je suis pas la pour blamer
linux, je suis la pour faire en sorte de trouver
une solution
Pas l'endroit idéal pour ce genre de problème...
C'est pas vraiment un bug proprement dit, et pour l'affichage c'est peu être X11 qui est en cause, en je me sens pas super à l'aise en anglais.
Déjà rien que je post en francais n'as bien fait parler, je me sens pas de refaire la même discutions en anglais.

Poste le Tuesday 15 July 2008 15:12:36
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO

Une remarque générale: il n'est pas certain que la mesure du temps CPU (sous Linux comme sous Windows) soit extrêmement précise. Il pourrait même être probable que sous Windows ça soit moins précis, car dans tous les cas il faut instrumenter le noyau, et Microsoft n'aurait aucun intérêt à distribuer son système avec le code d'instrumentation (on devine bien que Microsoft a intérêt au contraire à ne pas distribuer une version instrumentée de son noyau).

Citation
alpha_one_x86
Les IO (réseau ou hdd) sous linux prennent du temps cpu qui ne peut pas être utilisé par des applications. Sous windows ce n'est pas le cas, tests à l'appui.

Je n'y crois pas vraiment. Windows (comme n'importe quel système d'exploitation) doit faire des traitements comparables à ceux de Linux pour le réseau comme pour le disque. Le traitement d'un paquet IP sur ethernet, ou d'une interruption disque SATA, n'est gratuit pour aucun OS! Et les systèmes de fichiers windowsien n'ont pas une réputation d'efficacité. De plus, les serveurs windowsiens sont plus lourds et nécessitent plus de ressources que l'équivalent linuxien (autrement, tout le monde utiliserait Windows sur ses serveurs, où le coût des licences logicielles est toujours négligeable sur les autres coûts, l'essentiel du TCO étant la main d'oeuvre pour le support.).

Par contre, l'affichage X11 est évidemment bien plus onéreux qu'un affichage Windowsien, parce que X11 est un serveur (capable de fonctionner en réseau), ce que n'est pas la solution windowsienne.

L'équivalent linuxien de l'affichage windowsien (uniquement local) serait plutôt les solutions locales (sans protocole réseau) comme DirectFB mais il y a de bonnes raisons pour les éviter.

Mais je n'ai pas tout compris des problèmes que alpha_one_x86 cherchent à résoudre
[v](car ses fautes nombreuses de français me sont trop pénibles à lire, et détournent mon attention)[/v].

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 15 July 2008 15:22:29
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

L'utilisation du cpu est + ou - proportionnel à ça consommation, et mon ampéremétre est précis, ... ;-)

Un peu teste intéressant sous ram disque:
Kaffeine: 60% d'utilisation du cpu
Vlc: 10% pas de lag lors du défilement d'une page web
Sous windows:
Vlc: 2% pas de lag lors du défilement d'une page web mais c'est commun à tout les lecteurs video et toute les applications.

Mon ampérémettre fait un bon sous kaffeine, sous vlc et linux il augmente de 0.6A sous windows avec vlc j'ai une augmentation de 0.08A.

Pour Basile STARYNKEVITCH:
- Dans l'interface X11 un élément peu en faire ramer un autre, et l'affichage de nombreux est lourd mais temps réel sous windows
- Les IO prennes des temps cpu sous linux est pas sous windows, (teste cpu priorité basse avec dd ou autre IO pour s'en rendre compte)
Il n'aurai pas été plus simple de faire un affichage local et une solution distante car la majorité des utilisateurs utilise leur X11 en local.

Poste le Tuesday 15 July 2008 15:57:06
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

PS: meme teste pour la lecture brute d'un hdd et d'un fichier sur le réseau:
linux: 3.6A avec utilisation d'un cœur à 100%.
window: 1.2A avec le cpu à 3%.

Poste le Tuesday 15 July 2008 16:01:19
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO

Est-ce que le disque dur est bien configuré (hdparm) notamment pour faire du DMA?

Mais comme d'autres, je suis sceptique sur la méthodologie, et j'ai beaucoup de mal à comprendre la motivation... (pourquoi perdre ton temps à çà?).

As tu essayé un autre OS libre (FreeBSD, Syllable)?

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 15 July 2008 17:40:09
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: ofkain

Bonjour,

Je rejoinds basile sur le dma, et re insiste sur ce point, X11 et co n'ont rien a voir la dedans, ce probleme est somme toute plutot simple, ce qu'il se passe est que en l'absence de l'activation du dma, ton OS donne tous les traitements de fichiers a faire par le CPU, au lieu du DMAC...
Donc pour commencer, hdparm -i /dev/sd??, hdparm -t /dev/sd??, make menuconfig du noyau pour verifier que tout est bien configurer ( et je peux presque t'assurer que ca ne l'est pas vu les chiffres )

Et pour finir sur le sujet de windows qui cache certaines choses, c'est vrai et faux en meme temps. Je m'explique, pour un transfert de disque a disque, comme je l'ai dis plus haut, tout passe par le dmac, donc 0% ( ou presque ) d'utilisation du CPU, c'est comme ca sur toutes mes machines.
Par contre, lors d'un transfert sur usb par exemple, la je note une relativement faible, mais bien existante utilisation du CPU ( de l'ordre de 5 a 15% ) et la raison en est tres simple, l'usb n'utilise pas de dma ( ceci n'est cependant pas une règle générale... voir doc du kernel ) et la, effectivement, dans ce cas windows masque l'utilisation CPU faite par les IO.

Je me permets donc de reinsister sur le fait que ton problème est seulement un problème de configuration du noyau... il existe plusieures options a activer, n'ayant pas de noyau sous la main je ne peux pas te les lister, mais en tout cas, il est sur que hdparm te diras que ton disque n'est pas en dma ( a ne pas confondre avec les mode UDMA[0-6]... )

Poste le Tuesday 15 July 2008 18:49:01
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: diancech

Bon aprés quelques petits tests que je viens de faire, je reviens sur ce que j'ai dit pas de problème avec gmplayer.

La config :
Matériel:
AMD Athlon XP 3000+
Carte nvidia GeForce 6600
1Go de RAM
je vous passe le reste ;-)

Logiciel:
Windows XP
Debian Lenny (installée il y a un mois, pas tripotée :-)) ).

Les pourcentages CPU je les ai lu (en temps qu'utilisateur basique ^^D-* ) dans le moniteur Système sous windows et sous top sous linux.

Copie de fichier basique de disque à disque sous windows avec l'explorateur de fichier et sous linux avec rox-filer:

Sous windows : 30% de CPU utilisée pendant la copie.
Sous linux: 10% de CPU.
Ce qui doit correspondre à la consommation des effets graphiques imageant la copie des fichiers je pense.

Lecture de vidéos avec VLC sous windows et Linux avec des déplacements de fenêtre (Explorateur de fichier sous windows et rox-filer sous linux):

Sous windows: VLC en fonctionnement 2% de CPU -> Quand je déplace la fenêtre le CPU monte à 99% et la vidéo se fige il ne reste plus que le son.
Sous linux : VLC en fonctionnemment 10% de CPU -> Quand je déplace la fenêtre le CPU monte à 48% et la vidéo reste fluide sans saccade.
Donc la gestion des fenêtres des applications sous windows n'est pas bien faite puisque la vidéos se fige en déplaçant une fenêtre, tandis que sous linux les fenêtres sont bien gérés indépendamment puisque la vidéo est fluide lors du déplacement de fenêtre.

C'est sûr que c'est un benchmark un peu à la louche (et sans doute un peu bidon, il aurait fallu que j'utilise des logiciels spécifique mesurant les IO et le %CPU par processus sur les deux OS mais j'ai un peu la flême :-))), en tout cas je ne rencontre pas le genre de problème que tu as alors que la debian lenny vient d'être installé sans prendre le temps de faire le ménage dans les services inutiles et autres chose que je pourrai customiser (système de fichier, ...)

Donc je rejoins ofkain, à mon avis il y a des choses de mal configuré sur ta (tes) machine(s).

Je referai les tests avec mon autre configuration Gentoo AMD64 sur de l'intel core2duo avec une nvidia 8800 GTX et 2 Go de ram pour voir les résultats. ;-)




--------------------------------------------------------------------------------------------------------------------------------------------------
Exige beaucoup de toi-même et attends peu des autres. Ainsi beaucoup d'ennuis te seront épargnés. Confucius

Poste le Tuesday 15 July 2008 20:06:42
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Ca viens peu étre de la:
hdparm -d /dev/sda

/dev/sda:
 HDIO_GET_DMA failed: Inappropriate ioctl for device
amber ~ # hdparm -d /dev/sdb

/dev/sdb:
 HDIO_GET_DMA failed: Inappropriate ioctl for device

hdparm -i /dev/sda /dev/sdb

/dev/sda:

 Model=ST31000340AS                            , FwRev=SD04    , SerialNo=            3QJ00GJJ
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953523055
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode


/dev/sdb:

 Model=ST31000340AS                            , FwRev=SD15    , SerialNo=            9QJ034DY
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

hdparm -t /dev/sda /dev/sdb

/dev/sda:
 Timing buffered disk reads:  180 MB in  3.02 seconds =  59.62 MB/sec

/dev/sdb:
 Timing buffered disk reads:  176 MB in  3.01 seconds =  58.55 MB/sec
A moins que la sata fausse les mesures.

Je perd mon temps car ça rame, surtout dans certaine condition, et car j'aimerai une réactivité optimal comme sous windows, surtout avec les pc qui ont une grosse carte graphique.

Les autre unix j'ai pas encore essayer. Je vais m'y mettre un jour.

J'ai les meme résultat sous linux mais sous windows tout est différent chez moi. L'utilisation du cpu reste à vide pour le déplacement des fénétres video comme vlc, et idem pour la copie de fichier (gros ou petit)

En un coup de config:
cat config | grep DMA
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_ZONE_DMA32=y
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_DMAR is not set
CONFIG_ISA_DMA_API=y
CONFIG_SCSI_DMA=y
# CONFIG_PDC_ADMA is not set
# CONFIG_PATA_OPTIDMA is not set
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_DMADEVICES=y
# DMA Devices
CONFIG_INTEL_IOATDMA=m
CONFIG_DMA_ENGINE=y
# DMA Clients
CONFIG_NET_DMA=y
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_HAS_DMA=y

Je croise les doigt pour que ce soit moi qui est mal config, mais ca serai bizard que ça me le fasse pour toute les distro même celle que j'ai pas faite.
Je rejoins diancech dans les résultats linux, pas dans ceux windows.

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Tuesday 15 July 2008 22:11:00
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Avec un autre pc, j'ai ces résultat sur le déplacement de vlc, mais toujours pas sur le copier coller.
Moi je trouve qu'il y as une grosse différence en 2% et 10% d'utilisation du cpu, surtout que le décodage/encodage des video est aussi rapide sous linux que sous windows. Surtout que je suis surtout à 0% sous windows avec un meilleur pc.
Je continu à chercher.

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Tuesday 15 July 2008 22:17:43
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO

Citation
alpha
Ca vient peut-étre de là:
hdparm -d /dev/sda

/dev/sda:
 HDIO_GET_DMA failed: Inappropriate ioctl for device
amber ~ # hdparm -d /dev/sdb

/dev/sdb:
 HDIO_GET_DMA failed: Inappropriate ioctl for device

Oui, très probablement.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Wednesday 16 July 2008 18:10:48
Répondre     Citer    
Re: Temps noyau intempestifs lors d'IO
Envoyé par: alpha_one_x86

Sachant aussi que tout mes disque dur sata font la même réaction.
La lib sata est peu être en cause.
Même résultat avec un disque ide gérer par la lib sata.

Je continu à chercher.

Mon projet Qt/KDE de copieur de fichiers multi-plateformes, multi-protocoles, intégration par défaut dans un maximum d'OS:
[ultracopier.first-world.info]

Poste le Wednesday 16 July 2008 22:25:00
Répondre     Citer    
Aller à la page:  Page précédente 1 2 3 4 Page suivante
Page: 2 sur 4

Veuillez vous authentifier auparavant pour commenter.

 

Ce forum !
Temps noyau intempestifs lors d'IO
Posez dans ce forum les questions qui ne trouvent pas place dans les autres...
Nouveau sujet sur ce forum

Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons