Re: [PATCH 01/04] Adding cipher mode context information tocrypto_tfm

[Fruhwirth Clemens]

On Thu, 2005-02-10 at 12:54 -0500, James Morris wrote:

> Making a generic N-way scatterlist processor is pointless
> overengineering, causing new problems with non-trivial solutions, for
> no benefit whatsoever.

I respectfully disagree. I spend the last few days thinking about a
solution about optimally scheduling the constrained number of kmaps. The
number of kmap/kunmaps can easily be reduced by allocating on a
first-come-first-serve base, and keeping a shared kmap for all other.
This is optimal in terms of kmap/kunmaps, but it's not in terms of
memcpy bouncing for fragmented scatterlists.

Now, I found a solution for optimal mapping/remapping to minimize the
bouncing, but in fact it doesn't make sense anymore, because, even
though my algorithm does not enforce any single unnecessary pass over
the scatterlist set, it needs to book-keep too much queues, that their
maintenance causes more work than the memcpy work it tries to prevent.
It only safes work, when the stepsize is irregularly large, like >200
byte. I would have to introduce an artificial threshold level to decide
between memcpy-preventing behavior and the behavior outlined in the last
paragraph.

This is all getting more ugly than the ugliness I'm trying to escape. 

Conclusion: The idea of high-mem and low-mem seperation is fundamentally
broken. The limitation of page table entries to a fixed set is causing
more complications than it solves. Laziness to do things right at memory
management shifts the burden to the users of the interface. 

Being disgusted by the highmem interface and the "ungenericness" of my
generic workaround, there is not going to be any update to my LRW work
from my side. This patch set is dead.

-- 
Fruhwirth Clemens <clemens@xxxxxxxxxxxxx>  http://clemens.endorphin.org

Attachment: signature.asc
Description: This is a digitally signed message part