From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 26 05:29:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3424E501 for ; Wed, 26 Dec 2012 05:29:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id B990C8FC13 for ; Wed, 26 Dec 2012 05:29:12 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so3149070wgb.3 for ; Tue, 25 Dec 2012 21:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AuExUctz/rnNTNEJ5LyfbNPjM8EQb00vBhielWOaq8M=; b=iGb+d0T9oMhM4/gfWdykWchH4HHwCCVzIpXCt8T3wZ/pzHfgjn/4trPcRcFecckJvP aCj4xBqqj1Ophq6dUHUpq7Nb9yTa7+FW9k2LxSQiAvwzwj+fjGaaWXbcH4cT+dhZ0XRN 9rm1usl1X1IjExdCmcQEYFu9tQUpvKvuI3Ut1EBPaMYHOjqsxb9hcKvH7Va9h764Cto8 tOB9kP+TG4YBhvNXLEaVxkULEjrqyokt073SP/+st7VMiEHq9VfkPRm5rW95wrjaZo34 HZii4Ty2UIiHNadJ6kIoK8qAKClLoBtXpfgix3pdjjH13jli6MnXaRXHyO7ktF4GzPGH aGcg== MIME-Version: 1.0 Received: by 10.180.93.133 with SMTP id cu5mr33420194wib.32.1356499751881; Tue, 25 Dec 2012 21:29:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 25 Dec 2012 21:29:11 -0800 (PST) In-Reply-To: <20121226025115.91860@gmx.com> References: <20121226025115.91860@gmx.com> Date: Tue, 25 Dec 2012 21:29:11 -0800 X-Google-Sender-Auth: nlufSE_Akev4UHTmwixQsY3fDZE Message-ID: Subject: Re: FreeBSD for serious performance? From: Adrian Chadd To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 05:29:13 -0000 Hi, If the driver is doing something daft like DELAY(x) in a fast interrupt handler which would lead to that behaviour, it should be fixed. If it's doing a DELAY(x) in a critical section, it shuld be fixed. Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can preempt that. I don't agree with this behaviour, but it's possible. Now, it's quite likely you hit some kind of ata(4) bug which kept it in a tight loop without some kind of "too many errors; bailing" behaviour. I'm not an ata driver person; i have no idea why it's doing that. The driver shouldn't be disabling interrupts for other devices. That happens in critical sections and when doing lock operations. ata(4) doesn't call critical_* in the driver code. So it was likely just spun in some high priority loop that nothing lower-priority could really do anything about. The next time it happens, please break into the debugger and grab some debugging output. Show alllocks, ps, should be a good couple of things to start with. Alternately - please find a currently actively maintained SATA chipset. (Or Alternatively - step up and help migrate the nvidia chipset support out of ata(4).) Adrian