Re: Asynch I/O gets easily overloaded on 2.2.15 and 2.3.99

[Andi Kleen]

On Tue, Apr 11, 2000 at 03:14:44PM +0200, Andrea Arcangeli wrote:
> On 11 Apr 2000, Andi Kleen wrote:
> 
> >The culprit is probably the elevator code in ll_rw_blk, which uses
> >a single linked list, and possible the related queue walking code in
> >the SCSI driver. These queues are walked all the time to coalesce read/write
> 
> That shouldn't be the case. Also note that new elevator merges requests in
> O(1) if they are requesting contigous sectors. 2.2.x algorithm is O(N)
> also for merging requests of contiougs I/O instead.
> 
> If they are seeking all over the place then, yes we have an O(n)
> complexity there but the queue is limited. It's hard limit and you are
> hitting such limit _each_ time you write to disk some mbyte of data. So if
> you have not hangs while kupdate runs, then the elevator isn't going to be
> the culprit.

I was more thinking about lots of wakeups in get_request_wait causing the 
elevator to do much work (kupdate is single threaded so there are only a 
few wakeups).  With lots of threads calling ll_rw_block in parallel it may look 
differently.

> 
> >requests. You can check by booting with profile=2
> >and then using /usr/sbin/readprofile to get profile logs. The bad
> >routine should clearly show off.
> 
> If the elevator would be the culprit you would have no-way to catch it
> with the profiler since it always runs with the irq disabled due the
> io_request_lock that have to be acquired during I/O completation irqs.

Hmm, shouldn't a lot of the profiling hit the final sti when the interrupts
are enabled again ? 

> 
> Anyway I'm fairly confident that the profiler will show the real culprit
> (I guess Jeff is queueing into the buffer hashtable an insane number of
> buffers and that is causing complexity troubles due too much collisions).
> If that's the case you'll see you'll see an huge number in the
> get_hash_table entry in the profiling.
> 
> Also last time I checked the buffer hash was been shrunk because in 2.3.x
> the buffer cache isn't used for the data write I/O but the raw devices can
> still be used to read/write without a filesystem...

Good point. inode hash is too big, buffer hash is too small ...

-Andi