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

[Greg Oster <oster%cs.usask.ca@localhost>]

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