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
