Messages in this thread |  | | | Date | Mon, 28 May 2001 23:20:31 +0200 | | From | Jens Axboe <> | | Subject | Re: [patch] 4GB I/O, 2nd edition |
| |
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/
|  |