Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264268AbTEaKiV (ORCPT ); Sat, 31 May 2003 06:38:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264269AbTEaKiV (ORCPT ); Sat, 31 May 2003 06:38:21 -0400 Received: from blackbird.intercode.com.au ([203.32.101.10]:46340 "EHLO blackbird.intercode.com.au") by vger.kernel.org with ESMTP id S264268AbTEaKiU (ORCPT ); Sat, 31 May 2003 06:38:20 -0400 Date: Sat, 31 May 2003 20:51:04 +1000 (EST) From: James Morris To: "David S. Miller" cc: joern@wohnheim.fh-wedel.de, , , , Subject: Re: [PATCH RFC] 1/2 central workspace for zlib In-Reply-To: <20030530.232004.115919834.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 May 2003, David S. Miller wrote: > From: James Morris > 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 - 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/