Date: Sat, 31 May 2003 10:11:29 +0200
From: =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de>
To: "David S. Miller" <davem@redhat.com>
Cc: jmorris@intercode.com.au, linux-mtd@lists.infradead.org,
       linux-kernel@vger.kernel.org, kernel@kolivas.org
Subject: Re: [PATCH RFC] 1/2 central workspace for zlib
Message-ID: <20030531081129.GA26179@wohnheim.fh-wedel.de>
References: <20030531064851.GA20822@wohnheim.fh-wedel.de> <20030530.235505.23020750.davem@redhat.com> <20030531075615.GA25089@wohnheim.fh-wedel.de> <20030531.005909.68051039.davem@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20030531.005909.68051039.davem@redhat.com>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org

On Sat, 31 May 2003 00:59:09 -0700, David S. Miller wrote:
> 
> You can't leave the per-cpu workspace in an indeterminate
> state, you'll context switch and meanwhile that workspace will
> be used by another client or you'll next get scheduled on
> a different cpu and use a different workspace.

Did you read the patch?

When getting scheduled, the workspace remains associated with the
owning process ( z->workspace, z->ws_num ).  Other processes trying to
grab a workspace will get put on a waitqueue ( zlib_workspace_sem ).

The workspace is not exactly per cpu, it is per process.  Just the
amount of workspaces happens to be equal to the amount of cpus in the
system, but a couple more or less should work just as well.  

In softirq context you would be right.  Preempt is disabled anyway and
cpu affinity comes for free.

J?rn

-- 
A defeated army first battles and then seeks victory.
-- Sun Tzu
-
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/