On Fri, 2014-07-25 at 09:08 +0200, Peter Zijlstra wrote:
> On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
> > +/* Called in workqueue context, do one real cryption work (via
> > + * req->complete) and reschedule itself if there are more work to
> > + * do. */
>
> You seem to manage the 'normal' comment style in other places, this one
> 'special' for a reason?
Yes, I'll need to correct it.
>
> > +static void mcryptd_queue_worker(struct work_struct *work)
> > +{
> > + struct mcryptd_cpu_queue *cpu_queue;
> > + struct crypto_async_request *req, *backlog;
> > + int i;
> > +
> > + /*
> > + * Need to loop through more than once for multi-buffer to
> > + * be effective.
> > + */
> > +
> > + cpu_queue = container_of(work, struct mcryptd_cpu_queue, work);
> > + i = 0;
> > + while (i < MCRYPTD_BATCH || single_task_running()) {
> > + /*
> > + * preempt_disable/enable is used to prevent
> > + * being preempted by mcryptd_enqueue_request()
> > + */
> > + local_bh_disable();
> > + preempt_disable();
> > + backlog = crypto_get_backlog(&cpu_queue->queue);
> > + req = crypto_dequeue_request(&cpu_queue->queue);
> > + preempt_enable();
> > + local_bh_enable();
> > +
> > + if (!req)
> > + return;
> > +
> > + if (backlog)
> > + backlog->complete(backlog, -EINPROGRESS);
> > + req->complete(req, 0);
> > + if (!cpu_queue->queue.qlen)
> > + return;
> > + ++i;
> > + }
> > + if (cpu_queue->queue.qlen)
> > + queue_work(kcrypto_wq, &cpu_queue->work);
> > +}
>
> Right, so I don't think you need that single_task_running() thing for
> this. Also its a rather inconclusive test, a task can come in while
> processing the request, preempt the processing, complete and by the time
> we're back to check if we want to continue the loop its only us again.
>
> So its actually misleading..
>
> You could do that, but then you have to keep preemption disabled across
> the entire thing, and break out on need_resched(), that would entirely
> obviate the need for single_task_running(), but would increase the
> preemption latency by however long the req processing takes, so that's
> bad too.
>
> But you can get similar 'fuzzy' semantics as above by using something
> like:
>
> static inline bool did_context_switch(unsigned long *nivcs)
> {
> if (*nivcs != current->nivcs) {
> *nivcs = current->nivcs;
> return true;
> }
> return false;
> }
>
> static void mcryptd_queue_worker()
> {
> ...
> unsigned long nivcs = current->nivcs;
>
> ...
>
> while (!did_context_switch(&nivcs) || i < MCRYPTD_BATCH)
Won't I need something like
while ((!did_context_switch(&nivcs) && single_task_running())
|| i < MCRYPTD_BATCH)
in case I got some new task in my run queue but I did not get
pre-empted? I should not continue to run in that case.
>
> ...
> }
>
> It'll terminate earlier I suppose, its the inverse test. But I think you
> want to terminate early if there's any activity.
I have some doubts here.
If I'm still the only task running, why not continue, even if I've been
pre-empted? Since there's nothing else to run, why not take
advantage of the cpu?
Thanks.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
