Date: Mon, 16 Apr 2012 14:39:12 -0700 From: Adrian Chadd <adrian@freebsd.org> To: gljennjohn@googlemail.com Cc: freebsd-hackers <freebsd-hackers@freebsd.org>, Jerry Toung <jrytoung@gmail.com> Subject: Re: CAM disk I/O starvation Message-ID: <CAJ-VmokwR%2BVHmup6OLN%2BBGHvoAeLvJ9%2BBeZ9Fm6xM7Pio73pzQ@mail.gmail.com> In-Reply-To: <20120411192153.5672b62c@ernst.jennejohn.org> References: <CADC0LV=-e%2B7PshRQdc69e2-Vktf6XFpVrqiMpx=QL4m_%2B9hSnw@mail.gmail.com> <20120403193124.46ad9de9@ernst.jennejohn.org> <CADC0LVm1HY2Dz%2BVk_GK35szRS6ySviLhMiL1TSRBOnPwQnBwRg@mail.gmail.com> <20120411192153.5672b62c@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 April 2012 10:21, Gary Jennejohn <gljennjohn@googlemail.com> wrote: > Just for the archive my bad disk performance seems to have been fixed in > HEAD by svn commit r234074. =A0Seems that all interrupts were being handl= ed > by a single CPU/core (I have 6), which resulted in abysmal interrupt > handling when mutltiple disks were busy. > > Since this commit my disk preformance is back to normal and long lags > are a thing of the past. Hi, This is kind of worrying. You only have a few disks, a single core SHOULD be able to handle all the interrupts for those disks whilst leaving plenty of cycles to spare to drive the rest of your system. And you have 5 other cores. Would you be willing to help out diagnose exactly why that particular behaviour is causing you so much trouble? It almost sounds like something in the IO path is blocking for far too long, not allowing the rest of the system to move forward. That's very worrying for an interrupt handler. :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokwR%2BVHmup6OLN%2BBGHvoAeLvJ9%2BBeZ9Fm6xM7Pio73pzQ>