Date: Tue, 25 Dec 2012 21:29:11 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Dieter BSD <dieterbsd@engineer.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD for serious performance? Message-ID: <CAJ-VmonbwNpykKPCFNxHcyoU7-qLa2LbsREJQ0oci0wL6d1=pg@mail.gmail.com> In-Reply-To: <20121226025115.91860@gmx.com> References: <20121226025115.91860@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonbwNpykKPCFNxHcyoU7-qLa2LbsREJQ0oci0wL6d1=pg>