lkml.org 
[lkml]   [2000]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel 2.2.14, dirty buffers, stalls in interactivity of system/NFS-clients ...
Date
On Tue, 28 Mar 2000, Daniel J Blueman wrote:
> When init loads the update (bdflush) daemon, it simply exists at the first
> flush (5s later?), since the kflushd kernel thread is doing the work. That's
> why you cannot see the updated/bdflush process. I think the version of
> bdflush you have doesn't matter, in this case.

Okay. I was just a concerned newbie. Some document I hit
mentioned that bdflush was no longer used in the latest 2.2 kernels.

> You'll need to get some parameters tuned though to see better performance.
> If you can tune the I/O subsystem such that it flushes dirty data every 5s
> (.'. in a much smaller bursts), since the RAID controller will deal with it
> asyncoronsouly, it shouldn't cause your system to grind to a halt.

Tune the I/O subsystem? I think that is _exactly_ what I am
looking for, but have absolutely _no_idea_ where to begin. I've
hit the source (apparently not enough ;-), but would like to hear
any suggestions anyone has.

And I _do_ concur that I need to flush regularly instead of less
frequenty. When I get a big write, it seems that Linux will just
let the memory fill up and then write when its full. While this is
fine for a workstation, it's killer on a server with NFS clients
(the SMB clients are not affected).

> This large flush every 30s

Actually, these large "flushes" happen only occassionally (every 30
minutes), but for 15-60s. That's the problem.

> may be larger than the write-back buffers in your RAID controller

Yes, that is exactly it.

My GDT controller has 64MB of RAM, but it is flushing 200MB+ to
disk. Hence why the RAID controller reports 30-50% full and it
seems to go up and down (as the controller is feed data to write
by the OS). The second the controller just starts steadily going
down, the "stall" ends because the controller is no longer being
feed data (still writing to disk, but not the PCI bus).

> such that the whole process becomes disk I/O bound, not PCI
> bus I/O bound.

Yep. When the controller is just flushing its own cache, it's no
problem. It's when it's being feed over the PCI bus, that's the
problem.

> As said, try reducing the time interval to 5s - you want a
> quiescent flow of data onto your disks, not too bursty.

Er, I have not figured out how to do that exactly. And I've read
quite a bit. Do I do it with ./update? Do I have to reboot for
the changes to take effect (I hope not)?

Sorry for such a newbie question.

-- TheBS

--
Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker
E-mail: mailto:thebs@theseus.com,b.j.smith@ieee.org
Disclaimer: http://www.SmithConcepts.com/legal.html
*************************************************************
TheBS ... Serving E-mail filters to /dev/null since 1989


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:2.082 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site