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 15:32:02 -0700
Brian Buhrow <buhrow%nfbcal.org@localhost> wrote:

>       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. 

Yes...

> 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?

This is approximately the maximum memory needed, yes.  Actual memory
used in a non-degraded situation would typically be much less.

Later...

Greg Oster

> 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
> 


Later...

Greg Oster