On Wed, 13 Mar 2013 15:32:02 -0700 Brian Buhrow <[email protected]> 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 <[email protected]> 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
