On Tue, 17 Apr 2012 12:30:15 -0700
Adrian Chadd wrote:
> On 17 April 2012 12:15, Gary Jennejohn wrote:
> > I still have the old problem kernel around, but it's probably not
> > instrumented for any meaningful diagnoses.
>
> Well do you know which version of which tree you used to build that?
>
On Tue, Apr 17, 2012 at 09:15:58PM +0200, Gary Jennejohn wrote:
> ...
> I still have the old problem kernel around, but it's probably not
> instrumented for any meaningful diagnoses.
> ...
Several months ago, I was running a set of meaurements (to determine how
performance for a certain task varie
On 17 April 2012 12:15, Gary Jennejohn wrote:
> Yes, I agree completely. My first thought was that disk I/O
> scheduling had somehow been pessimized. But then I thought -
> wait a minute, I have disk caches enabled and command queuing is
> enabled for all of them, so that shouldn't really have
On Mon, 16 Apr 2012 14:39:12 -0700
Adrian Chadd wrote:
> On 11 April 2012 10:21, Gary Jennejohn wrote:
>
> > Just for the archive my bad disk performance seems to have been fixed in
> > HEAD by svn commit r234074. Seems that all interrupts were being handled
> > by a single CPU/core (I have 6)
On 11 April 2012 10:21, Gary Jennejohn wrote:
> Just for the archive my bad disk performance seems to have been fixed in
> HEAD by svn commit r234074. Seems that all interrupts were being handled
> by a single CPU/core (I have 6), which resulted in abysmal interrupt
> handling when mutltiple dis
On Tue, 3 Apr 2012 14:27:43 -0700
Jerry Toung wrote:
> On 4/3/12, Gary Jennejohn wrote:
>
> > It would be interesting to see your patch. I always run HEAD but maybe
> > I could use it as a base for my own mods/tests.
> >
>
> Here is the patch
>
[patch removed]
Just for the archive my bad d
On Wed, Apr 4, 2012 at 8:22 PM, Alexander Leidinger wrote:
>
> This looks fair if all your disks are working at the same time (e.g.
> RAID only setup), but if you have a setup where you have multiple
> disks and only one is doing something, you limit the amount of tags
> which can be used. No ide
On Thu, 5 Apr 2012 05:22:46 +0200
Alexander Leidinger wrote:
> On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung
> wrote:
>
> > On 4/3/12, Gary Jennejohn wrote:
> >
> > > It would be interesting to see your patch. I always run HEAD but
> > > maybe I could use it as a base for my own mods/tests.
On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung
wrote:
> On 4/3/12, Gary Jennejohn wrote:
>
> > It would be interesting to see your patch. I always run HEAD but
> > maybe I could use it as a base for my own mods/tests.
> >
>
> Here is the patch
This looks fair if all your disks are working at
On 4/3/12, Gary Jennejohn wrote:
> It would be interesting to see your patch. I always run HEAD but maybe
> I could use it as a base for my own mods/tests.
>
Here is the patch
diff -rup cam/cam_sim.c cam/cam_sim.c
--- cam/cam_sim.c 2010-06-13 19:09:06.0 -0700
+++ cam/cam_sim.c
On Mon, 2 Apr 2012 10:55:31 -0700
Jerry Toung wrote:
> I am convinced that there is a bug in the CAM code that leads to I/O
> starvation.
> I have already discussed this privately with some. I am now bringing this up
> to
> the general audience to get more feedback.
>
I've observed this with
Hello list,
I am convinced that there is a bug in the CAM code that leads to I/O starvation.
I have already discussed this privately with some. I am now bringing this up to
the general audience to get more feedback.
My setup is that I have 1 RAID controller with 2 arrays connected to
it, da0 and d
12 matches
Mail list logo
