> From: James Morris <jmorris@intercode.com.au>
> Date: Sat, 31 May 2003 01:29:42 +1000 (EST)
>
> This won't work for the bh lock protected case outlined above, and
> will cause contention between different users of zlib.
>
> My understanding is that these are just scratchpads. The contents
> while a decompress/compress operation is not occuring does not
> matter.
It depends on how the zlib library is used. The filesystems and crypto
code use it so that each operation is distinct, although it is possible to
maintain compression history between operations: PPP does this via a
sliding compression window, and there are other potential users such as
ROHC.
One way of addressing this would to allow the user to supply their own
workspace if compression history needs to be maintained.
> So if we have 2 such scratchpads per cpu, one for normal and one for
> BH context, his idea truly can work and be useful to everyone.
> It would also be lockless on SMP.
And perhaps implement with a lazy allocation scheme so that these
scratchpads are only allocated if needed (i.e. a caller does not provide
its own workspace).
- James
-- James Morris <jmorris@intercode.com.au>- 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/