[ I've sent it to Linus a moment ago, here is a copy for linux-{ide,kernel} ]
Highlights of this update:
* the code for selecting and programming the best DMA transfer mode
has been reworked to be cleaner, more generic and more libata-like,
( 500 LOCs gone and this change allows the change
Bartlomiej Zolnierkiewicz wrote:
Bartlomiej Zolnierkiewicz (11):
ide: fix UDMA/MWDMA/SWDMA masks (v3)
ide: rework the code for selecting the best DMA transfer mode (v3)
ide: add ide_tune_dma() helper
ide: make /proc/ide/ optional
ide: split off ioctl handling from
Bartlomiej Zolnierkiewicz wrote:
* the code for selecting and programming the best DMA transfer mode
has been reworked to be cleaner, more generic and more libata-like,
( 500 LOCs gone and this change allows the change described below)
Bartlomiej Zolnierkiewicz (11):
ide: rework the
Andrew Morton wrote:
Jeff Garzik [EMAIL PROTECTED] wrote:
Has this seen testing/exposure in -mm tree?
argh. If this was in a file called
ide-rework-the-code-for-selecting-the-best-DMA-transfer-mode.patch then it
would be so easy.
logs into hera
greps
ah, it's hidden in
Bartlomiej Zolnierkiewicz wrote:
On Thursday 10 May 2007, Jeff Garzik wrote:
The limit was raised to 400K IIRC.
That's (good) news to me, here goes the actual 150K patch:
Thanks. I did in fact receive copies from vger, so it went through.
Jeff
-
To unsubscribe from this list:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 09 May 2007 18:46:16 -0400
Bartlomiej Zolnierkiewicz wrote:
Bartlomiej Zolnierkiewicz (11):
ide: fix UDMA/MWDMA/SWDMA masks (v3)
ide: rework the code for selecting the best DMA transfer mode (v3)
ide: add ide_tune_dma()
On 8/19/05, Alan Cox [EMAIL PROTECTED] wrote:
On Gwe, 2005-08-19 at 11:02 +0200, Bartlomiej Zolnierkiewicz wrote:
lkml.org/lkml/2005/1/27/20
AFAIK CS5535 driver was never ported to 2.6.x. Somebody needs to
port it to 2.6.x kernel, cleanup to match kernel coding standards and test.
Hi,
3 obvious fixes + support for 2 new controllers
(just new PCI IDs).
Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6.git
diffstat/changelog/patch below
--
Bartlomiej
drivers/ide/Kconfig |1 +
drivers/ide/ide-floppy.c |2 +-
On 8/18/05, Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 18 Aug 2005, Bartlomiej Zolnierkiewicz wrote:
3 obvious fixes + support for 2 new controllers
(just new PCI IDs).
Btw, things like this:
+#define IDEFLOPPY_TICKS_DELAY HZ/20 /* default delay for ZIP 100
Linus Torvalds wrote:
Btw, things like this:
+#define IDEFLOPPY_TICKS_DELAY HZ/20 /* default delay for ZIP 100
(50ms) */
are just bugs waiting to happen.
Needs parenthesis: ((HZ)/20)
Or one could just use the msecs_to_jiffies() macro.
Cheers
-
To unsubscribe from this list:
On Maw, 2005-07-05 at 20:14, Jens Axboe wrote:
IDE still has much lower overhead per command than your average SCSI
hardware. SATA with FIS even improves on this, definitely a good thing!
But SCSI overlaps them while in PATA they are dead time. Thats why PATA
is so demanding of large I/O block
* Jens Axboe [EMAIL PROTECTED] wrote:
But! I used hdparm -t solely, 2.6 was always ~5% faster than 2.4. But
using -Tt slowed down the hd speed by about 30%. So it looks like some
scheduler interaction, perhaps the memory timing loops gets it marked
as batch or something?
to check whether
On Fri, 2005-07-08 at 10:06 +1000, Grant Coady wrote:
I've not been able to get dual channel I/O speed faster than single
interface speed, either as 'md' RAID0 or simultaneous reading or
writing done the other day:
Time to write or read 500MB file:
summary 2.4.31-hf1
On Fri, Jul 08 2005, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
But! I used hdparm -t solely, 2.6 was always ~5% faster than 2.4. But
using -Tt slowed down the hd speed by about 30%. So it looks like some
scheduler interaction, perhaps the memory timing loops gets it
On 7/6/05, Bill Davidsen [EMAIL PROTECTED] wrote:
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
Bill Davidsen wrote:
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%
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% user 33% sys 65% idle
Note:
hdparm can also use O_DIRECT for the -t timing test.
Eg. hdparm --direct -t /dev/hda
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 07 Jul 2005 18:32:52 -0400, Mark Lord [EMAIL PROTECTED] wrote:
hdparm can also use O_DIRECT for the -t timing test.
I've not been able to get dual channel I/O speed faster than single
interface speed, either as 'md' RAID0 or simultaneous reading or
writing done the other day:
Time to
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.
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
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
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:
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.
Bartlomiej Zolnierkiewicz wrote: {
Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6.git
}
Does it fix the idedriver int/dma problem?
Al
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Bartlomiej Zolnierkiewicz wrote: {
Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6.git
}
Does it fix the idedriver int/dma problem?
What is the int/dma problem?
-
To unsubscribe from this list: send the line
Bartlomiej Zolnierkiewicz wrote: {
What is the int/dma problem?
}
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 73% IOWAIT
It feels like DMA is not being applied
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Bartlomiej Zolnierkiewicz wrote: {
What is the int/dma problem?
}
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
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 73% IOWAIT
It feels like DMA is
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 73% IOWAIT
It feels
On 7/4/05, Ondrej Zary [EMAIL PROTECTED] 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
On 7/4/05, Al Boldi [EMAIL PROTECTED] 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%
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 73% IOWAIT
The
46 matches
Mail list logo
