Date: Wed, 7 Jul 2010 15:29:15 +0200
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.hengli.com.au>
Cc: Dan Kruchinin <dkruchinin@acm.org>,
       Andrew Morton <akpm@linux-foundation.org>, linux-crypto@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: [PATCH 0/6] padata: updates
Message-ID: <20100707132915.GV10072@secunet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1592
Lines: 40

This patchset contains the following changes:

1. Add a flag to mark the padata instance as invalid.
We will use this to mark the padata instace as invalid
if the padata cpumask contains no active cpu.

2. Make padata_stop to block until the padata instance is
unused. So it's save to change the cpumask after a call to
padata_stop.

3. Add a possibility to handle empty padata cpumasks.
The first three patches address a bug, found by Dan Kruchinin.
When the padata cpumask does not intersect with the active
cpumask we get a division by zero in padata_alloc_pd and we
end up with a useless padata instance. It's not possible to
trigger this bug by now, but Dan has patches that let the
cpumask change from userspace. So this bug has to be fixed
before these patches can go in.

4. Make padata_do_parallel to return zero on success.
To return -EINPROGRESS on success was considered to be odd,
so we change the API to return zero instead. Users are updated
accordingly.

5. Simplify the serialization mechanism.
As it is, we go through all the percpu reorder queues to calculate
the sequence number of the next object that needs serialization. 
This patch avoids this and minimalizes the accesses of foreign
memory. This gives some performance inprovements, in particular
on machines with many cpus.

6. Update the padata documentation.

Steffen

--
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/