André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda /dev/null gives 2% user 33% sys 65% idle
Hdparm -tT gives 28mb/s in 2.6.12
Cat /dev/hda /dev/null gives 2% user 25% sys 0% idle
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda /dev/null gives 2% user 33% sys 65% idle
Hdparm -tT gives 28mb/s
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda /dev/null gives 2%
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda
On Tue, 2005-07-05 at 14:35 +0200, Ondrej Zary wrote:
2.4.26
[EMAIL PROTECTED]:/home/rainbow# time dd if=/dev/hda of=/dev/null bs=512
count=1048576
1048576+0 records in
1048576+0 records out
real0m23.858s
user0m1.750s
sys 0m15.180s
Perhaps some read-ahead bug. What
Jens Axboe wrote:
On Tue, 2005-07-05 at 14:35 +0200, Ondrej Zary wrote:
2.4.26
[EMAIL PROTECTED]:/home/rainbow# time dd if=/dev/hda of=/dev/null bs=512
count=1048576
1048576+0 records in
1048576+0 records out
real0m23.858s
user0m1.750s
sys 0m15.180s
Perhaps some read-ahead bug.
Hi,
I just installed the new bios version, but it doesn't help.
Nobody cared errors with enhanced mode, and no dma support in compatibility
mode.
Anyone has an idea what I can try ? Should I add this to the bugzilla on
kernel.org ?
Thanks
Felix
Am Friday, 1. July 2005 18:01 schrieb Felix
Jens Axboe wrote:
On Tue, 2005-07-05 at 15:02 +0200, Ondrej Zary wrote:
Ok, looks alright for both. Your machine is quite slow, perhaps that is
showing the slower performance. Can you try and make HZ 100 in 2.6 and
test again? 2.6.13-recent has it as a config option, otherwise edit
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, 2005-07-05 at 15:02 +0200, Ondrej Zary wrote:
Ok, looks alright for both. Your machine is quite slow, perhaps that is
showing the slower performance. Can you try and make HZ 100 in 2.6 and
test again? 2.6.13-recent has it as
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, 2005-07-05 at 15:02 +0200, Ondrej Zary wrote:
Ok, looks alright for both. Your machine is quite slow, perhaps that is
showing the slower performance. Can you try and make HZ 100 in 2.6 and
test again?
On Tue, 5 Jul 2005, Jens Axboe wrote:
Looks interesting, 2.6 spends oodles of times copying to user space.
Lets check if raw reads perform ok, please try and time this app in 2.4
and 2.6 as well.
I think it's just that 2.4.x used to allow longer command queues. I think
MAX_NR_REQUESTS is
I'm wondering if anyone can shed some light on the following error.
The software I am running is a 2.6.11 kernel from the CVS at
www.linux-mips.org, using the sata_promise driver. I believe the
libata and sata_promise drivers are exactly the same as the vanilla
2.6.11 kernel. I have also
On Tue, Jul 05 2005, Linus Torvalds wrote:
On Tue, 5 Jul 2005, Jens Axboe wrote:
Looks interesting, 2.6 spends oodles of times copying to user space.
Lets check if raw reads perform ok, please try and time this app in 2.4
and 2.6 as well.
I think it's just that 2.4.x used to allow
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, 2005-07-05 at 15:02 +0200, Ondrej Zary wrote:
Ok, looks alright for both. Your machine is quite slow, perhaps that is
showing the slower performance. Can you
On Tue, Jul 05 2005, Ondrej Zary wrote:
oread is faster than dd, but still not as fast as 2.4. In 2.6.12, HDD
led is blinking, in 2.4 it's solid on during the read.
Oh, and please do test 2.6 by first setting the deadline scheduler for
hda. I can see you are using the 'as' scheduler right now.
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
oread is faster than dd, but still not as fast as 2.4. In 2.6.12, HDD
led is blinking, in 2.4 it's solid on during the read.
Oh, and please do test 2.6 by first setting the deadline scheduler for
hda. I can see you are using the 'as'
Jens Axboe wrote:
On Tue, Jul 05 2005, Linus Torvalds wrote:
On Tue, 5 Jul 2005, Jens Axboe wrote:
Looks interesting, 2.6 spends oodles of times copying to user space.
Lets check if raw reads perform ok, please try and time this app in 2.4
and 2.6 as well.
I think it's just that 2.4.x
Hi Jeff,
i'd like to know if you, or somebody else is working at the Linux
support of the PDC40719 chipset of Promise. I cant find any informations
about this question in Google or the Mailing-Lists.
Greetings
Ulf
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the
On Tue, 5 Jul 2005 16:21:26 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
# gcc -Wall -O2 -o oread oread.c
# time ./oread /dev/hda
Executive Summary
``
Comparing 'oread' with hdparm -tT on latest 2.4 vs 2.6 stable on
various x86 boxen. Performance drops for 2.6, sometimes:
After finally getting fed up with not having my activity light working
for my SATA drives, I came up with a small patch (more like hack) to
make it work. It works quite well, but I'm afraid that there are many
restriction that this patch does not check for that it probably
should... so consider
Linus Torvalds wrote: {
On Wed, 6 Jul 2005, Grant Coady wrote:
Executive Summary
Btw, can you try this same thing (or at least a subset) with a large file on
a filesystem? Does that show the same pattern, or is it always just the raw
device?
}
Linus,
Cat /dev/hda /dev/null and cat
On Tue, 5 Jul 2005 17:51:50 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED]
wrote:
Btw, can you try this same thing (or at least a subset) with a large file
on a filesystem? Does that show the same pattern, or is it always just the
raw device?
Sure, take a while longer to vary by block size.
22 matches
Mail list logo
