All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <lkml@dervishd.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: usb-storage nice value
Date: Thu, 17 May 2007 12:34:36 +0200	[thread overview]
Message-ID: <20070517103436.GA15329@DervishD> (raw)
In-Reply-To: <20070517111901.202309d9@the-village.bc.nu>

    Hi Alan :)

 * Alan Cox <alan@lxorguk.ukuu.org.uk> 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!

  reply	other threads:[~2007-05-17 10:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-17 10:03 usb-storage nice value DervishD
2007-05-17 10:19 ` Alan Cox
2007-05-17 10:34   ` DervishD [this message]
2007-05-17 19:53 ` Stefan Richter
2007-05-18  6:15   ` DervishD
2007-05-18  6:33     ` Jan Engelhardt
2007-05-18  8:21       ` DervishD
2007-05-18  8:49         ` Jan Engelhardt
2007-05-18 11:13           ` DervishD
2007-05-18  9:46 ` Heikki Orsila
2007-05-18 11:12   ` DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070517103436.GA15329@DervishD \
    --to=lkml@dervishd.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.