Date: Mon, 14 Feb 2005 09:07:26 -0800
From: "David S. Miller" <davem@davemloft.net>
To: Fruhwirth Clemens <clemens@endorphin.org>
Cc: jmorris@redhat.com, akpm@osdl.org, linux-kernel@vger.kernel.org,
       michal@logix.cz, adam@yggdrasil.com
Subject: Re: [PATCH 01/04] Adding cipher mode context information to
 crypto_tfm
Message-Id: <20050214090726.2d099d96.davem@davemloft.net>
In-Reply-To: <1108400799.23133.34.camel@ghanima>
References: <Xine.LNX.4.44.0502101247390.9159-100000@thoron.boston.redhat.com>
	<1108387234.8086.37.camel@ghanima>
	<20050214075655.6dec60cb.davem@davemloft.net>
	<1108400799.23133.34.camel@ghanima>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 988
Lines: 21

On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens <clemens@endorphin.org> wrote:

> There is nothing wrong with having special methods, that lack generality
> but are superior in performance. There is something wrong, when there
> are no other. And there are no other for holding three kmappings or more
> concurrently.

You want more resources in a context where no such thing exists,
in interrupt processing context.  There the stack is limited, allocatable
memory is limited, etc. etc. etc.  And all of this is because you cannot
sleep in interrupt context.

Resources are fixed in this environment exactly becuase one cannot
sleep or wait on events.  It's supposed to be fast processing, deferring
more involved work to process context.
-
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/