From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 18 22:56:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FDA1065670 for ; Sun, 18 Mar 2012 22:56:34 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id D03CC8FC0A for ; Sun, 18 Mar 2012 22:56:33 +0000 (UTC) Received: (qmail 18759 invoked by uid 0); 18 Mar 2012 22:56:33 -0000 Received: from 67.206.186.200 by rms-us004.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Sun, 18 Mar 2012 18:56:29 -0400 From: "Dieter BSD" Message-ID: <20120318225630.155070@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-drivers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: SQ0Ub/dd3zOlNR3dAHAhK4h+IGRvb4AB Cc: Subject: Reigning in disk cache buffer hogs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 22:56:34 -0000 amd64 4 GiB nVidia nForce CK804 (aka nforce4-ultra), SiI3132, JMB363 sata disks FreeBSD 8.2 FFS/SU Problem: I/O to one disk can fill up the disk buffer cache, starving other processes of disk I/O.  If the other processes are logging real time data (from a closed source "black box"), then data is lost.  Each process has its own private disk to minimise latency due to seeking and such, but that isn't sufficient to prevent the problem. It is always the onboard nforce4-ultra controller that causes the problem. The expansion card controllers never cause the problem. The onboard nforce4-ultra controller is supported by ata(4). The expansion card controllers are supported by ahci(4) and siis(4). The onboard nforce4-ultra controller is much faster than the expansion card controllers, except that ata doesn't support NCQ, so the nforce has a serious bottleneck writing. Is there something about NCQ other than the obvious performance improvement that would explain why the NCQ controllers never have the problem? What sort of miracle would it take to get NCQ support for the nforce4-ultra controller?  Linix has had NCQ support since 2006. Is there some knob to control reserving a few buffers per disk to prevent one disk from hogging all the buffer cache?