[lkml]   [2004]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: Further aacraid work
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 ( 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.076 / U:4.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site