Hi all :)
I'm using kernel 2.6.19.5.
I'm having problems when reading/writing to external USB harddisks:
my *internal* harddisk stalls from time to time, so watching a movie
while copying data is a PITA (well, if the movie is bad, the leaps help
a bit...).
I thought about lowering the nice value of usb-storage (currently
it's -5), but if USB disks are not involved, the "leaps" in movies or
audio still happen when writing large amounts of data. I've tested with
different internal disks, and it doesn't happen with latest 2.4.x (at
least, it doesn't happen so annoyingly, leaps seldom happen, while with
2.6.x it's continuous).
My system is a bit modest: a 7 years old motheboard with VIA686B, a
1900+ Athlon XP, but with plenty of RAM (1280MB + 1GB swap). I know, if
I want more hard disk performance I should buy a new box with SATA or
whatever, but the fact is that I hadn't problems with the same hardware
and kernel 2.4.x. I need 2.6.x, so I cannot go back to 2.4.x.
Since messing with the nice values of kernel threads doesn't look
right to me, is there any way of modifying the pdflush behaviour so
large buffered writes are less "agressive" and doesn't block apps which
are just reading? If messing with pdflush (well, /proc/whatever) is a
bad idea too, where should I look for culprits so I can tweak the system
a bit and improve disk performance? I'm not 100% sure that the problem
is related *only* with the new kernel, but my problem is that I cannot
carry long tests (e.g. running a 2.4 for some days with my normal usage
pattern to see if the problem happens there: it doesn't happen in a
fresh boot 2.4 and it happens in a fresh boot 2.6)
Thanks a lot in advance, and feel free to ask whatever you need to
lend a hand O:)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
> My system is a bit modest: a 7 years old motheboard with VIA686B, a
> 1900+ Athlon XP, but with plenty of RAM (1280MB + 1GB swap). I know, if
> I want more hard disk performance I should buy a new box with SATA or
> whatever, but the fact is that I hadn't problems with the same hardware
> and kernel 2.4.x. I need 2.6.x, so I cannot go back to 2.4.x.
Disk is actually less likely to be a problem than PCI bus bandwidth - the
older VIA boards seem quite happy to fill the PCI bus solid during bursts
of disk I/O
> bad idea too, where should I look for culprits so I can tweak the system
> a bit and improve disk performance? I'm not 100% sure that the problem
You might want to try the reverse if you have a UDMA100 or UDMA133 drive
then setting the speed down to UDMA66 definitely evens out the behaviour
of VIA boards when doing video capture. I don't know if it helps playback.
Alan
Hi Alan :)
* Alan Cox <[email protected]> dixit:
> > My system is a bit modest: a 7 years old motheboard with VIA686B, a
> > 1900+ Athlon XP, but with plenty of RAM (1280MB + 1GB swap). I know, if
> > I want more hard disk performance I should buy a new box with SATA or
> > whatever, but the fact is that I hadn't problems with the same hardware
> > and kernel 2.4.x. I need 2.6.x, so I cannot go back to 2.4.x.
>
> Disk is actually less likely to be a problem than PCI bus bandwidth - the
> older VIA boards seem quite happy to fill the PCI bus solid during bursts
> of disk I/O
I was supposing something in that line, since disk speed is quite
high (when I only read or write but not both). I just didn't think about
PCI bandwidth.
> > bad idea too, where should I look for culprits so I can tweak the system
> > a bit and improve disk performance? I'm not 100% sure that the problem
>
> You might want to try the reverse if you have a UDMA100 or UDMA133 drive
> then setting the speed down to UDMA66 definitely evens out the behaviour
> of VIA boards when doing video capture. I don't know if it helps playback.
Won't that reduce disk performance when using just one disk? I don't
pass much data between disks (or even copy data within one disk), so not
being able to watch movies while copying data is, for me, more
acceptable than having a slower disk all the time.
And yes, all my disks are UDMA100.
Is there a way of changing chipset behaviour from userspace so PCI
bus is not filled during IO bursts?
Thanks a lot for your answer, Alan :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
DervishD wrote:
> I'm having problems when reading/writing to external USB harddisks:
> my *internal* harddisk stalls from time to time, so watching a movie
> while copying data is a PITA (well, if the movie is bad, the leaps help
> a bit...).
If the internal harddisk is source or target of these copy operations...
...
> is there any way of modifying the pdflush behaviour so
> large buffered writes are less "agressive" and doesn't block apps which
> are just reading?
...then switching to another IO scheduler might perhaps help.
# cat /sys/block/hda/queue/scheduler
# echo deadline > /sys/block/hda/queue/scheduler
--
Stefan Richter
-=====-=-=== -=-= =---=
http://arcgraph.de/sr/
Hi Stefan :)
* Stefan Richter <[email protected]> dixit:
> DervishD wrote:
> > I'm having problems when reading/writing to external USB harddisks:
> > my *internal* harddisk stalls from time to time, so watching a movie
> > while copying data is a PITA (well, if the movie is bad, the leaps help
> > a bit...).
>
> If the internal harddisk is source or target of these copy operations...
Not...
> ...
> > is there any way of modifying the pdflush behaviour so
> > large buffered writes are less "agressive" and doesn't block apps which
> > are just reading?
>
> ...then switching to another IO scheduler might perhaps help.
>
> # cat /sys/block/hda/queue/scheduler
>
> # echo deadline > /sys/block/hda/queue/scheduler
That's another thing I wanted to test, but I'm already using
"deadline" scheduler. How about changing "read_ahead_kb" to a much
higher value so there's plenty of data buffered? The problem seems to
be, according to Alan Cox, that my VIA mobo fills completely the PCI bus
when doing IO bursts, so I can take advantage of that "bug" and fill the
bus when reading.
My only doubt is if it will affect performance negatively in other
usage patterns (e.g. while writing CD's, since the hard disk will take
the bus on each read operation, and will read more than the current 128
kB).
Thanks a lot for your answer :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On May 18 2007 08:15, DervishD wrote:
>Date: Fri, 18 May 2007 08:15:12 +0200
>From: DervishD <[email protected]>
>To: Stefan Richter <[email protected]>
>Cc: [email protected]
>Subject: Re: usb-storage nice value
Try ionice.
>> DervishD wrote:
>> > I'm having problems when reading/writing to external USB harddisks:
>> > my *internal* harddisk stalls from time to time, so watching a movie
>> > while copying data is a PITA (well, if the movie is bad, the leaps help
>> > a bit...).
>>
>> If the internal harddisk is source or target of these copy operations...
>
> Not...
>
>> ...
>> > is there any way of modifying the pdflush behaviour so
>> > large buffered writes are less "agressive" and doesn't block apps which
>> > are just reading?
>>
>> ...then switching to another IO scheduler might perhaps help.
>>
>> # cat /sys/block/hda/queue/scheduler
>>
>> # echo deadline > /sys/block/hda/queue/scheduler
>
Or try echo 10 >/proc/sys/kernel/dirty_ratio
> That's another thing I wanted to test, but I'm already using
>"deadline" scheduler. How about changing "read_ahead_kb" to a much
>higher value so there's plenty of data buffered? The problem seems to
>be, according to Alan Cox, that my VIA mobo fills completely the PCI bus
>when doing IO bursts, so I can take advantage of that "bug" and fill the
>bus when reading.
>
> My only doubt is if it will affect performance negatively in other
>usage patterns (e.g. while writing CD's, since the hard disk will take
>the bus on each read operation, and will read more than the current 128
>kB).
Jan
--
Hi Jan :)
* Jan Engelhardt <[email protected]> dixit:
> Try ionice.
I didn't know about it, probably I didn't install it the last time I
built util-linux. Anyway, I've seen an ionice in
Documentation/block/ioprio.txt (which, BTW, I missed when searching for
information about my problem).
> Or try echo 10 >/proc/sys/kernel/dirty_ratio
Not in my proc :?? Perhaps /proc/sys/vm/dirty_ratio? Mine is 40,
which I think is too high.
Thanks!
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On May 18 2007 10:21, DervishD wrote:
>
>> Or try echo 10 >/proc/sys/kernel/dirty_ratio
>
> Not in my proc :?? Perhaps /proc/sys/vm/dirty_ratio? Mine is 40,
>which I think is too high.
Linus also thinks it is too high; I do not really care what it is set
at, as it depends on the use case.
Jan
--
On Thu, May 17, 2007 at 12:03:08PM +0200, DervishD wrote:
> I'm having problems when reading/writing to external USB harddisks:
> my *internal* harddisk stalls from time to time, so watching a movie
> while copying data is a PITA (well, if the movie is bad, the leaps help
> a bit...).
I've had a similar problem that is caused due to USB write caching. When
a process rapidly writes to a USB device, the whole memory gets filled
with write cache. When the memory is full of write cache for USB, it is
very slow to get clean pages as the USB device is slow. This stalls the
entire system performance. Using sync mount option for USB solves this
problem, but decreases write performance significantly.
Would it be possible to limit per device write caching to N pages from
userspace? Having just 128 MiB of write cache for a USB device would be
sufficient for high performance, but yet have plenty of clean pages for
other purposes.
--
Heikki Orsila Barbie's law:
[email protected] "Math is hard, let's go shopping!"
http://www.iki.fi/shd
Hi Heikki :)
* Heikki Orsila <[email protected]> dixit:
> On Thu, May 17, 2007 at 12:03:08PM +0200, DervishD wrote:
> > I'm having problems when reading/writing to external USB
> > harddisks: my *internal* harddisk stalls from time to time, so
> > watching a movie while copying data is a PITA (well, if the
> > movie is bad, the leaps help a bit...).
>
> I've had a similar problem that is caused due to USB write caching.
> When a process rapidly writes to a USB device, the whole memory gets
> filled with write cache. When the memory is full of write cache for
> USB, it is very slow to get clean pages as the USB device is slow.
> This stalls the entire system performance.
I'm not sure if this is my problem, since the external USB disks
seem to be at least as fast as the internal one (I've not noticed the
device to be slow at all). I'm going to use the same sets of disks in
another system that doesn't have an old VIA chipset, to see if the
problem is the PCI-fill one.
BTW, using "sync" mount option doesn't help: it just makes the data
copying slower, but when the data is burst-written, the internal hard
disk stalls for a bit. The stalls are shorter, though.
> Would it be possible to limit per device write caching to N pages from
> userspace? Having just 128 MiB of write cache for a USB device would be
> sufficient for high performance, but yet have plenty of clean pages for
> other purposes.
Probably the "dirty_ratio" setting will help, I'm going to test it
this weekend. I don't know if there are a per-device setting to tell how
many pages can be used as cache.
Thanks for answering :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
Hi Jan :)
* Jan Engelhardt <[email protected]> dixit:
>
> On May 18 2007 10:21, DervishD wrote:
> >
> >> Or try echo 10 >/proc/sys/kernel/dirty_ratio
> >
> > Not in my proc :?? Perhaps /proc/sys/vm/dirty_ratio? Mine is 40,
> >which I think is too high.
>
> Linus also thinks it is too high; I do not really care what it is set
> at, as it depends on the use case.
I'll make some tests this weekend to find a good value for me,
starting at 10.
Again, thanks :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!