Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
Status from this message: Thanks, applied!
Get series with b4
b4 am [email protected]Versions newest first
Patches in v1 Applied
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Jens Axboe |
|---|---|
| Series | Was-Signed-by |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
As Jens said, there is nothing common to scsi_sgtable and sglists. Save the fact that it is a massive conflict at scsi-ml. They touch all the same places.
Proposed is a simple way out. Two patchsets That produce the same output at the end.
One: scsi_sgtable_than_sg-chaining
Two: sg-chaining_than_scsi_sgtable
They are layed out like this
common to both
[PATCH AB1/5] SCSI: SG pools allocation cleanup
scsi_sgtable_than_sg-chaining:
[PATCH A2/5] SCSI: scsi_sgtable implementation [PATCH A3/5] SCSI: sg-chaining over scsi_sgtable
sg-chaining_than_scsi_sgtable:
[PATCH B2/5] SCSI: support for allocating large scatterlists [PATCH B3/5] SCSI: scsi_sgtable over sg-chainning
Both patchsets are based on linux-2.6-block sglist-drivers (or sglist-arch) on top of a:
git-revert 630cfe6f8a137a3d494aefda1e62bc4b9ba02f58.
Revert of "SCSI: support for allocating large scatterlists"
First patch will not apply on scsi-misc-2.6 because there
is a missing NULL in the call to kmem_cache_create(). (linux-2.6.23-rcx) (If any one need a patchset for that please ask)
What we need to do first is agree on the outcome of both sgtable and sglist chaining combined. The easiest way is to look at the 1st patchset AB1/5, A2/5, A3/5. It is the most incremental and easy to read.
(Note: This patchset is part of a larger patchset as I sent in my last RFC "scsi-ml: scsi_sgtable implementation". You can find a revised set here: www.bhalevy.com/open-osd/downloads/scsi_sgtable)
If we all agree on the combined outcome, than we can proceed to decide which route to take.
What I would like to ask of Jens is: please review the first 2 patches from the B patchset. AB1/5, B2/5. These together are almost exactly like your reverted patch above, but are a bit more friendly to the scsi_sgtable at the end.
For James the first patch [AB1/5] is a good patch that solves real world problems today, like HIGHME64G=y. And maximizes allocations for all kind of ARCHs. Maybe it could be applied to the tree now for the next merge window, regardless of what is done with the rest.
I'm just starting to test large IO's ontop of iSCSI. So probably some bugs will be found.
Thanks everybody
Boaz