Messages in this thread | | | Subject | Re: PATCH: Further aacraid work | From | Clay Haapala <> | Date | Thu, 17 Jun 2004 11:32:29 -0500 |
| |
On 17 Jun 2004, James Bottomley spake thusly: > On Thu, 2004-06-17 at 09:39, Salyzyn, Mark wrote: >> This would not be such an issue if Linux provided large SG elements >> rather than the fubar descending page order ones they issue today. If >> this could be fixed, I'd not even be interested in the optimization of >> the SG. > > This is hardly a big problem, is it? it only occurs during the first > few moments of system operation. After that, the pages assigned to a > virtual region are pretty much random. > > Fundamentally, sg lists have to operate at the level of the MMU, so > we're stuck with the page size, which is 4k on x86. There's nothing we > can do in SCSI about this. > > Of course, if you're on a platform with an IOMMU then this problem > simply doesn't exist and we can coalesce nicely. > > James
Just to see if my understanding is on track ...
Today's scatterlists already handle entries with a size greater than MMU pagelength, even on x86, right? We have seen it in iSCSI driver testing, though it is not the usual case. crypto/digests.c:update() function was recently patched to handle the case and properly kmap() the additional memory represented by the sg entry.
So, on regular x86 this is a matter of convenience/timing, and the page assignments will tend toward, but not always be, random 1-page entries as the system is used. -- Clay Haapala (chaapala@cisco.com) Cisco Systems SRBU +1 763-398-1056 6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD Overheard somewhere in Washington D.C.: "Doh! Invaded the wrong country!" - 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/
| |