On Wed, Jul 17, 2019 at 04:47:40PM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 10:28:15AM +0200, Steffen Klassert wrote:
> >
> > I had a patch to support crypto backlog some years ago,
> > but testing with dm-crypt did not show any performance
> > improvement. So I decided to just skip that
On Wed, Jul 17, 2019 at 10:36:41AM +0200, Steffen Klassert wrote:
>
> > This patch fixes it by using RCU just as we do in padata_do_parallel.
>
> RCU alone won't help because if some object is queued for async
> crypto, we left the RCU protected aera. I think padata_do_serial
> needs to do RCU and
On Wed, Jul 17, 2019 at 10:28:15AM +0200, Steffen Klassert wrote:
>
> I had a patch to support crypto backlog some years ago,
> but testing with dm-crypt did not show any performance
> improvement. So I decided to just skip that patch because
> it added code for no need.
Well pcrypt is part of the
On Tue, Jul 16, 2019 at 09:23:45PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 09:09:28PM +0800, Herbert Xu wrote:
> >
> > Hmm, it doesn't work because the refcnt is attached to the old
> > pd. That shouldn't be a problem though as we could simply ignore
> > the refcnt in padata_flush_queue
On Tue, Jul 16, 2019 at 09:09:28PM +0800, Herbert Xu wrote:
>
> However, I think this leads to another bug in that pcrypt doesn't
> support dm-crypt properly. It never does the backlog stuff and
> therefore can't guarantee reliable processing which dm-crypt requires.
>
> Is it intentional to onl
On Tue, Jul 16, 2019 at 03:50:10PM +0200, Peter Zijlstra wrote:
>
> Could well be, I'm not much familiar with this code; I'll look more
> careful.
My patch is broken anyway. We can't just switch pd structures
as the code relies on going to exactly the same CPU on the starting
pd to ensure orderin
On Tue, Jul 16, 2019 at 09:18:07PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 03:15:20PM +0200, Peter Zijlstra wrote:
> >
> > > @@ -367,7 +368,7 @@ void padata_do_serial(struct padata_priv *padata)
> > > struct parallel_data *pd;
> > > int reorder_via_wq = 0;
> > >
> > > - pd = padata
On Tue, Jul 16, 2019 at 09:09:28PM +0800, Herbert Xu wrote:
>
> Hmm, it doesn't work because the refcnt is attached to the old
> pd. That shouldn't be a problem though as we could simply ignore
> the refcnt in padata_flush_queue.
This should fix it:
---8<---
The function padata_do_serial uses pa
On Tue, Jul 16, 2019 at 03:15:20PM +0200, Peter Zijlstra wrote:
>
> > @@ -367,7 +368,7 @@ void padata_do_serial(struct padata_priv *padata)
> > struct parallel_data *pd;
> > int reorder_via_wq = 0;
> >
> > - pd = padata->pd;
> > + pd = rcu_dereference_bh(padata->inst->pd);
> >
> >
On Tue, Jul 16, 2019 at 08:57:04PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 01:14:10PM +0200, Steffen Klassert wrote:
> >
> > Maybe we can fix it if we call padata_free_pd() from
> > padata_serial_worker() when it sent out the last object.
>
> How about using RCU?
>
> We still need to f
On Tue, Jul 16, 2019 at 08:57:04PM +0800, Herbert Xu wrote:
>
> How about using RCU?
>
> We still need to fix up the refcnt if it's supposed to limit the
> overall number of outstanding requests.
Hmm, it doesn't work because the refcnt is attached to the old
pd. That shouldn't be a problem thoug
On Tue, Jul 16, 2019 at 01:14:10PM +0200, Steffen Klassert wrote:
>
> Maybe we can fix it if we call padata_free_pd() from
> padata_serial_worker() when it sent out the last object.
How about using RCU?
We still need to fix up the refcnt if it's supposed to limit the
overall number of outstanding
12 matches
Mail list logo
