[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Where is the component queue depth actually used in the raidframe system?
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.
> 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.
> 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
Main Index |
Thread Index |