Re: processes not getting fair share of available disk I/O

[ Available lists | Index of freebsd-questions | Month of Dec 2006 | Week of 14 Dec 2006 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Kris Kennaway <kris@obsecurity.org>
Date
14 Dec 2006 01:23:46
Subject
Re: processes not getting fair share of available disk I/O
Message-ID
20061214012035.GA62554@xor.obsecurity.org

In reply to
References to
Replies
Referenced by

[ Hide this part ]
On Wed, Dec 13, 2006 at 04:37:42PM +0000, Dieter wrote:
> > > Is Giant the only mutex/lock that could be a bottleneck across disks?
> >
> > The only one I can think of that is generic. One would have to do
> > more extensive profiling and diagnosis to try and figure out what is
> > wrong with your system.
>
> Suggestions of what to look at would be welcome.

Mutex profiling would show if there is a mutex somehow getting in the
way of your I/O (e.g. if Giant is somehow being forced). I dont think
it would show anything though. You can try to study interrupt issues
(e.g. look for an interrupt storm during I/O) with vmstat -i. Other
than that you'd probably have to get your hands dirtier in the code.

> > The only explanation that seems to fit is that it's something to do
> > with your particular hardware (i.e. driver issue), since it's
> > certainly not a problem on general configurations.
> >
> > I know that many people have bad things to say about nforce chipsets,
> > although I dont know if your particular problem has been reported
> > before.
>
> Could APIC have anything to do with this? It is currently turned off in
> firmware.

Problems with interrupt delivery could certainly be relevant.

> Today I experimented with vfs.hirunningspace. If I crank it up, I get
> better total write speed with multiple drives doing dd from /dev/zero
> to files on disks. But it doesn't help my real applications, and
> in fact appears to hurt them.

Yes, I don't expect there are any viable high-level workarounds for
this issue at a lower layer.

Kris

[ Show this part (application/pgp-signature) ]

Elapsed time: 0.103 seconds