> -----Message d'origine----- > De : linux-ide-owner@xxxxxxxxxxxxxxx > [mailto:linux-ide-owner@xxxxxxxxxxxxxxx] De la part de > Fortier,Vincent [Montreal] > > > -----Message d'origine----- > > De : Alan Cox [mailto:alan@xxxxxxxxxxxxxxxxxxx] > > > > > I made a fwe tests to try to point out when high loads happens > > > (which are not really scientific :). Note that between each tests I > > > made sure the load average got back below 0.15. > > > > > > But first, here are my 2 questions: > > > 1- Should I really expect loads that high using that driver? > > > > Remember that uptime type load also measure system wait so high disk > > I/O counts as load but not CPU usage. High CPU usage shouldn't be a > > problem for any DMA based disk > > > > With the newer ICH controllers and especially if your disk does NCQ > > you should see better performance with libata as the libata drivers > > support AHCI and NCQ which allows multiple outstanding commands. > > Maybie I should have explain that, I found this problem while > trying to compile a single kernel with -j1 or -j2 on this > dual core CPU and it made the load average climb to at least > 10. Doing more testing revealed that most writes to disks > made the load average climb seriously (Just dragging > 400-500mb of MP3 made the load climb really heavilly making > my system unresponsive)... Actually, just uncompressing > kernel sources makes my system unresponsive and that is not a > heavy task? > > However on my AMD 4200+ system at home with libata driver on > a nforce chipset I can compile 5 kernels at once using -j4 > for each compilation and I get a load of around 10-12 and > that is, I believe, a normal behaviour. > > This is why I believe that there is a bug in the E-IDE driver > and that switching to libata would greatly improve performances. > > > > "Multi-Platform E-IDE driver Revision: 7.00alpha2" and detected both > > > my hd & dvdrw as scsi devices BUT finally ended up in a oops: > > > pivot_root: No such file or directory > > > /sbin/init: 432: Cannot open dev/console: No such file Kernel panic > > > - not syncing: Attempted to kill init > > > > Thats really for the Debian lists, it sounds as if Debian still isn't > > using disk labels in the initrd. > > Yeah, I'll try to dig some more info on this. I tought it > would have been easier switching from one to the other... :( I've found what I was missing... As usual it wasn't much... It only was missing the proper loading of "sd_mod" module so that probed disk gets an assign device file. Here is my "howto for Debian Sarge 3.1" for any of you interested: 1- Added the "sd_mod" and "ata_piix" module to /etc/mkinitrd/modules 2- Recreated the appropriate initrd (In this case: mkinitrd -o /boot/initrd.img-2.6.20.10-cfs-sarge-686-envcan 2.6.20.10-cfs-sarge-686-envcan) 3- Updated the /etc/fstab to switch from hda to sda 4- Updated the /boot/grub/device.map to -> (hd0) /dev/sda (instead of: (hd0) /dev/hda) 5- Updated the grub mmenu.lst to switch hda to sda like: kernel /vmlinuz-2.6.20.10-cfs-sarge-686-envcan root=/dev/sda2 ro vga=0x305 6- Booted properly! > > > TEST 2: 10000 1mb files (medium size files): > > > Note that I stopped the test a the 4134th file) > > > ----------------------------------------------- > > > Max load average (a simple while loop + sleep 5 + cat /proc/loadavg) > > > 16.36 12.64 7.86 2/122 3602 > > > > If you are doing all the I/O in parallel then that isn't unexpected - > > disk performance is very very seek dependant snd a lot of parallel I/O > > will cause a lot of seeking. If they are occuring in serial then this > > is a bit odd and would warrant more investigating. I don't however > > think this is likely to be a disk layer problem so I doubt libata v > > oldIDE makes that much difference here - a bit because of NCQ but not > > a lot. > > This was serial testing (wich makes this odd): > > while [ $i -lt $MAX ] > do > declare TMP_FILE=`mktemp ${TEST_DIR}/${i}.XXXXXX` || exit 1 > dd if=/dev/zero of=${TMP_FILE} bs=${BS} count=${COUNT} 2>/dev/null > let i++ > done BTW, here is the hdparm using the old driver: > > > Alan > > > > Thnx for answering! > > - vin - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
