Re: PATCH: Further aacraid work

[Clay Haapala <chaapala@cisco.com>]

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!"