public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Heflin <rogerheflin@gmail.com>
To: Alex Bennee <kernel-hacker@bennee.com>
Cc: Robert Hancock <hancockr@shaw.ca>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: DMA not working on SATA?
Date: Thu, 27 Mar 2008 12:45:10 -0500	[thread overview]
Message-ID: <47EBDD26.3030303@gmail.com> (raw)
In-Reply-To: <1206612034.24437.5.camel@pitcairn.cambridgebroadband.com>

Alex Bennee wrote:
> On Wed, 2008-03-26 at 23:20 -0600, Robert Hancock wrote:
>> Alex Bennee wrote:
>>> Hi,
>>>
>>> Since I got my new machine I noticed it seemed to be running slower than
>>> I expected for a duel core machine including a lot of stuttering. After
>>> tweaking the BIOS settings from "Legacy" to "AHCI" I measured a doubling
>>> of read performance with hdparm but heavy IO still makes the machine
>>> sluggish, with top showing ~80% of the time in the wait state (and
>>> loadavg shooting up). This seems like a DMA problem because I was under
>>> the impression a task demanding IO should be able to sleep on a DMA
>>> completion rather than blocking everything else.
>> That's not what IOwait means. It basically means "nothing better to do 
>> than wait for IO to complete". If you have only one running task which 
>> is blocked waiting for IO you will always have high IOwait.
> 
> So if my loadavg shoots up at the same time (indicating more than one
> task wanting to run) does that infer that most of my tasks are IO
> starved and waiting for the disk to catch up with them?
> 
> The main problem is I'm not sure if my disk subsystem is running as fast
> as it should be. What sort of data rates should I be seeing from a
> modern SATA type setup?

50-70MB/second per disk, if you are doing single sequential reads/writes (alone, 
not together-if you are doing both at the same time or more than one at the sime 
time it will be worse), if you are doing a lot of seeks it can be pretty much 
any number below that.    The smaller the pieces of data that are being sent to 
disk, the worse things will be.   The speed is dependent mostly on the type of 
disk, each disk has a underlying inside/outside platter bits per second, and 
that is the limit that you won't ever exceed.

> 
> As Alan pointed out (and I missed) the dmesg shows DMA is enabled, it's
> just hdparam doesn't seem to be able to infer the fact (new IOTCLS for
> newer disk systems?).
> 
> I could be I've already peaked in my performance and I'm just making
> unrealistic demands on memory usage (I have been running cvsps after
> all ;-).
> 


  reply	other threads:[~2008-03-27 17:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.tM6egqVO3jg78PMZEi2Ne7NkjtI@ifi.uio.no>
2008-03-27  5:20 ` DMA not working on SATA? Robert Hancock
2008-03-27 10:00   ` Alex Bennee
2008-03-27 17:45     ` Roger Heflin [this message]
2008-03-26  9:59 Alex Bennee
2008-03-26  9:56 ` Alan Cox

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=47EBDD26.3030303@gmail.com \
    --to=rogerheflin@gmail.com \
    --cc=hancockr@shaw.ca \
    --cc=kernel-hacker@bennee.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox