Re: [patch] 4GB I/O, 2nd edition

[Jens Axboe <axboe@kernel.org>]

On Mon, May 28 2001, Marcelo Tosatti wrote:
> > Hi,
> > 
> > One minor bug found that would possibly oops if the SCSI pool ran out of
> > memory for the sg table and had to revert to a single segment request.
> > This should never happen, as the pool is sized after number of devices
> > and queue depth -- but it needed fixing anyway.
> > 
> > Other changes:
> > 
> > - Support cpqarray and cciss (two separate patches)
> > 
> > - Cleanup IDE DMA on/off wrt highmem
> > 
> > - Move run_task_queue back again in __wait_on_buffer. Need to look at
> >   why this hurts performance.
> 
> It decrease performance of what in which way ?

Initial dbench testing on a 3.5gb box showed a decrease in performance.
Which did not make sense to me, since there would be no reason to run
tq_disk if the buffer is not locked as is. In fact, I would have
expected this small change to increase performance slightly (which is
why I did it of course), we would be able to build longer queues. I
didn't do any queue monitoring, but I noted that __make_request scan
times were _smaller_ with this change. Which really doesn't make sense
at all :-)

So I'm suspecting a weird mm interaction, I'll drop more info as I find
out. Unfortunately I've been disconnected from above box since this
afternoon, so haven't been able to test since...

-- 
Jens Axboe