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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:37 EST