4GB I/O, 2nd edition
PATCH 1/1 4GB I/O, 2nd edition
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.
- Don't account front merge as sequence decrement in elevator (will not incur a seek)
- Dump info when highmem I/O is enabled, mainly for debugging
This version has run the cerberus hell-hound all night (IDE and SCSI), no bugs discovered. The patches were split up even more, for easier reading etc. It will not apply cleanly to latest 2.4.5-ac kernels, let me know if you want a version for that...
The patches (in apply order)
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.5/
- block-highmem-2
The highmem block infrastructure, and pci dma additions.
- zone-dma32-5
Adds the 32-bit dma capable memory zone and make highmem kmap both source and destination page.
- scsi-high-1
Adds general highmem support to the SCSI layer and selected low level drivers.
- ide-high-1
Adds general highmem support to the IDE layer and selected low level drivers.
- cpqarray-high-1
Adds highmem support to the Compaq smart array driver
- cciss-high-1
Adds highmem support to the 64-bit Compaq smart array driver
Signature · 1 line
Jens Axboe
Quoted 7 lines · Jens Axboe
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.
Quoted 8 lines
Other changes:
- Support cpqarray and cciss (two separate patches)
- Cleanup IDE DMA on/off wrt highmem
- Move
run_task_queueback again in__wait_on_buffer. Need to look at why this hurts performance.
It decrease performance of what in which way ?
Thanks
Quoted 9 lines · Marcelo Tosatti
Quoted 9 lines
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:
Quoted 8 lines
Quoted 6 lines
- Support cpqarray and cciss (two separate patches)
- Cleanup IDE DMA on/off wrt highmem
- Move
run_task_queueback 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...
Signature · 1 line
Jens Axboe