On Fri, Jul 19, 2019 at 10:37:21AM -0400, Daniel Jordan wrote:
>
> If I'm not missing anything, still looks like get_cpu() and reorder_via_wq no
> longer have an effect with this patch and can be removed.
You're right that they're not needed. But we shouldn't mix clean-ups
with substantial change
On Thu, Jul 18, 2019 at 11:01:46PM +0800, Herbert Xu wrote:
> @@ -376,9 +325,8 @@ void padata_do_serial(struct padata_priv *padata)
>
> cpu = get_cpu();
>
> - /* We need to run on the same CPU padata_do_parallel(.., padata, ..)
> - * was called on -- or, at least, enqueue the pad
On Thu, Jul 18, 2019 at 10:56:34PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote:
> >
> > That's what I expected when I first saw it too, but nr_cpumask_bits is
> > returned
> > to signal the end of the iteration. The patch always passes 0 for the
> > '
On Thu, Jul 18, 2019 at 10:49:50PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
> >
> > Which memory barrier do you mean? I think you're referring to the one that
> > atomic_inc might provide? If so, the memory model maintainers can correct
> > me
> >
The function padata_reorder will use a timer when it cannot progress
while completed jobs are outstanding (pd->reorder_objects > 0). This
is suboptimal as if we do end up using the timer then it would have
introduced a gratuitous delay of one second.
In fact we can easily distinguish between whet
On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote:
>
> That's what I expected when I first saw it too, but nr_cpumask_bits is
> returned
> to signal the end of the iteration. The patch always passes 0 for the 'start'
> argument, so when cpumask_next_wrap is called with the last cpu in
On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
>
> Which memory barrier do you mean? I think you're referring to the one that
> atomic_inc might provide? If so, the memory model maintainers can correct me
> here, but my understanding is that RMW atomic ops that don't return values
On Thu, Jul 18, 2019 at 11:31:31AM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 02:32:27PM -0400, Daniel Jordan wrote:
> >
> > We'll crash when cpumask_next_wrap returns nr_cpumask_bits and later try to
> > get
> > the corresponding per-cpu queue.
>
> The whole point of cpumask_next_wrap is
On Thu, Jul 18, 2019 at 11:30:08AM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 07:21:36PM -0400, Daniel Jordan wrote:
> >
> > > @@ -388,12 +336,12 @@ void padata_do_serial(struct padata_priv *padata)
> > > pqueue = per_cpu_ptr(pd->pqueue, cpu);
> > >
> > > spin_lock(&pqueue->reorder.lo
On Wed, Jul 17, 2019 at 02:32:27PM -0400, Daniel Jordan wrote:
>
> We'll crash when cpumask_next_wrap returns nr_cpumask_bits and later try to
> get
> the corresponding per-cpu queue.
The whole point of cpumask_next_wrap is to wrap around to the
beginning when it hits nr_cpumask_bits. So it cann
On Wed, Jul 17, 2019 at 07:21:36PM -0400, Daniel Jordan wrote:
>
> > @@ -388,12 +336,12 @@ void padata_do_serial(struct padata_priv *padata)
> > pqueue = per_cpu_ptr(pd->pqueue, cpu);
> >
> > spin_lock(&pqueue->reorder.lock);
> > - atomic_inc(&pd->reorder_objects);
> > list_add_tail
On Wed, Jul 17, 2019 at 07:11:47PM +0800, Herbert Xu wrote:
> Note that we don't bother removing the work queue in
> padata_flush_queues because the whole premise is broken. You
> cannot flush async crypto requests so it makes no sense to even
> try. A subsequent patch will fix it by replacing it
On Wed, Jul 17, 2019 at 07:11:47PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 12:32:53PM -0400, Daniel Jordan wrote:
> > Testing padata with the tcrypt module on a 5.2 kernel...
>
> Thanks for the patch!
>
> And here is an incremental patch to get rid of the timer that
> appears to be an
On Tue, Jul 16, 2019 at 12:32:53PM -0400, Daniel Jordan wrote:
> Testing padata with the tcrypt module on a 5.2 kernel...
Thanks for the patch!
And here is an incremental patch to get rid of the timer that
appears to be an attempt at fixing a problem related to this.
---8<---
The function padata
14 matches
Mail list logo
