From: Steffen Klassert <steffen.klassert@secunet.com>
To: Dan Kruchinin <dkruchinin@acm.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.hengli.com.au>
Subject: Re: [PATCH 1/3] padata: separate serial and parallel cpumasks
Date: Fri, 2 Jul 2010 11:17:26 +0200 [thread overview]
Message-ID: <20100702091726.GH10072@secunet.com> (raw)
In-Reply-To: <AANLkTinyPGjXjlvJxB8WYB3EYFBtANXMzpTdUixyBRHW@mail.gmail.com>
On Fri, Jul 02, 2010 at 01:07:44PM +0400, Dan Kruchinin wrote:
> >
> > The above is not save against cpu hotplug. You initialize ctx->cb_cpu
> > to -1 when the transformation is initialized. So you choose your
> > callback cpu with the first call to pcrypt_do_parallel() and then never
> > again. What if the coosen callback cpu goes offline?
> >
> > Also I don't understand why you changed the prototype of pcrypt_do_parallel
> > and added a 'count' to pcrypt_aead_ctx. The only change you have to do, is
> > to
> > check whether the choosen callback cpu is still in the cpu_active_mask
> > _and_
> > in your new padata callback cpumask and update the callback cpu accordingly
> > if not. Checking whether the callback cpu is in the callback cpumask needs
> > some special care in your other patch of course, because you can change
> > this
> > cpumask from userspace then.
> >
>
> Well, my point was to reduce the code and select callback CPU only once
> according to
> serial cpumask of given data instance. In case when I modify serial cpumask
> of given padata
> instance I have to do callback cpu calculation twice in worst case. The
> first time in pcrypt_aead_init_tfm
> and the second time in pcrypt_do_parallel if cb_cpu is not set in my serial
> cpumask.
> So I decided to do it only once in pcrypt_do_parallel.
>
But the active cpumask, and now also your serial cpumask might change.
We need to catch this changes somehow, that's why I checked the active
cpumask against the callback cpu.
Steffen
next prev parent reply other threads:[~2010-07-02 9:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTikeDE4hvZ3spyTBSHZsdQPc-2wlD5nTfb1aF-VD@mail.gmail.com>
2010-07-02 8:53 ` [PATCH 1/3] padata: separate serial and parallel cpumasks Steffen Klassert
[not found] ` <AANLkTinyPGjXjlvJxB8WYB3EYFBtANXMzpTdUixyBRHW@mail.gmail.com>
2010-07-02 9:17 ` Steffen Klassert [this message]
2010-07-02 9:32 ` Dan Kruchinin
2010-07-02 9:34 ` Dan Kruchinin
2010-07-02 11:11 ` Steffen Klassert
2010-07-02 13:01 ` Dan Kruchinin
2010-07-05 10:58 ` Steffen Klassert
[not found] ` <AANLkTimEgKGJ5pi7GzOnvP42ivJ4GCKX59LdKK0x4fnx@mail.gmail.com>
[not found] ` <20100706053612.GQ10072@secunet.com>
2010-07-06 5:44 ` Steffen Klassert
2010-07-06 7:40 ` Dan Kruchinin
2010-07-06 7:46 ` Steffen Klassert
2010-07-06 8:31 ` Dan Kruchinin
2010-07-06 13:28 ` Steffen Klassert
2010-07-06 16:30 ` Dan Kruchinin
2010-07-07 13:16 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100702091726.GH10072@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=dkruchinin@acm.org \
--cc=herbert@gondor.hengli.com.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.