Re: 2.6.24-rc6 reproducible raid5 hang

[Bill Davidsen <davidsen@tmr.com>]

Neil Brown wrote:
> On Wednesday January 9, dan.j.williams@intel.com wrote:
>   
>> On Jan 9, 2008 5:09 PM, Neil Brown <neilb@suse.de> wrote:
>>     
>>> On Wednesday January 9, dan.j.williams@intel.com wrote:
>>>
>>> Can you test it please?
>>>       
>> This passes my failure case.
>>     
>
> Thanks!
>
>   
>>> Does it seem reasonable?
>>>       
>> What do you think about limiting the number of stripes the submitting
>> thread handles to be equal to what it submitted?  If I'm a stripe that
>> only submits 1 stripe worth of work should I get stuck handling the
>> rest of the cache?
>>     
>
> Dunno....
> Someone has to do the work, and leaving it all to raid5d means that it
> all gets done on one CPU.
> I expect that most of the time the queue of ready stripes is empty so
> make_request will mostly only handle it's own stripes anyway.
> The times that it handles other thread's stripes will probably balance
> out with the times that other threads handle this threads stripes.
>
> So I'm incline to leave it as "do as much work as is available to be
> done" as that is simplest.  But I can probably be talked out of it
> with a convincing argument....
>   

How about "it will perform better (defined as faster) during conditions 
of unusual i/o activity?" Is that a convincing argument to use your 
solution as offered? How about "complexity and maintainability are a 
zero-sum problem?"

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark