Re: Processes stuck on D state on Dual Opteron

[Nick Piggin <nickpiggin@yahoo.com.au>]

Chen, Kenneth W wrote:
> Nick Piggin wrote on Tuesday, April 12, 2005 4:09 AM
> 
>>Chen, Kenneth W wrote:
>>
>>>I like the patch a lot and already did bench it on our db setup.  However,
>>>I'm seeing a negative regression compare to a very very crappy patch (see
>>>attached, you can laugh at me for doing things like that :-).
>>
>>OK - if we go that way, perhaps the following patch may be the
>>way to do it.
> 
> 
> OK, if you are going to do it that way, then the ioc_batching code in get_request
> has to be reworked.  We never push the queue so hard that it kicks itself into the
> batching mode.  However, calls to get_io_context and put_io_context are unconditional
> in that function.  Execution profile shows that these two little functions actually
> consumed lots of cpu cycles.
> 
> AFAICS, ioc_*batching() is trying to push more requests onto the queue that is full
> (or near full) and give high priority to the process that hits the last req slot.
> Why do we need to go all the way to tsk->io_context to keep track of that state?
> For a clean up bonus, I think the tracking can be moved into the queue structure.
> 

OK - well it is no different to what you had before these patches, so
probably future work would be seperate patches.

get_io_context can probably be reworked. For example, it is only called
with the current thread, so it probably doesn't need to increment the
refcount, as most users are only using it process context... all users
in ll_rw_blk.c, anyway.

-- 
SUSE Labs, Novell Inc.