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 <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
