Re: Where is the component queue depth actually used in the raidframe system?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

        hello.   What I'm seeing is that the underlying disks under both a
raid1 set and a raid5 set are not seeing anymore than 8 active requests at
once across the entire bus of disks.  This leaves a lot of disk bandwidth
unused, not to mention less than stellar disk performance.  I see that
RAIDOUTSTANDING is defined as 6 if not otherwise defined, and this suggests
that this is the limiting factor, rather than the actual number of requests
allowed to be sent to a component's queue.
        Just to clarify my understanding of the comment in rf_netbsdkintf.c,
the amount of memory required for each outstanding request is equal to
either 2 or 3 times the total number of bytes in each stripe plus the
incoming data request?

-thanks
-Brian
On Mar 13, 12:11pm, Greg Oster wrote:
} Subject: Re: Where is the component queue depth actually used in the raidf
} On Wed, 13 Mar 2013 10:47:18 -0700
} Brian Buhrow <buhrow%nfbcal.org@localhost> wrote:
} 
} >     Hello greg.  In looking into a performance issue I'm having
} > with some raid systems relative to their underlying disks, I became
} > interested in seeing how the component queue depth affects the
} > business of underlying disks.  To my surprise, it looks as if the
} > queue depth as defined in the raidx.conf file is never used.  Is that
} > really true?  The chain looks like: raidctl(8) sets 
} > raidPtr->maxQueueDepth = cfgPtr->maxOutstandingDiskReqs;
} > Then, in rf_netbsdkintf.c, we have:
} > d_cfg->maxqdepth = raidPtr->maxQueueDepth;
} > But I don't see where maxqdepth is ever used again.
} 
} Heh... Congrats!  I think you just found more 'leftovers' from when the
} simulator bits were removed (before RAIDframe was imported to NetBSD).
} In the simulation code maxQueueDepth was also assigned to
} threadsPerDisk which was used to fire off multiple requests to the
} simulated disk.  In the current code you are correct that maxqdepth is
} not used in any real meaningful way...  Unfortunately, we can't just
} rip it out without worrying about backward kernel-raidctl
} compatibility :( 
} 
} When you set maxOutstandingDiskReqs you're really setting
} maxOutstanding, and how that influences performance would be
} interesting to find out :)  Just be aware that the more requests you
} allow to be outstanding the more kernel memory you'll need to have
} available... 
} 
} Later...
} 
} Greg Oster
>-- End of excerpt from Greg Oster