From: Dave Gerlach <d-gerlach@ti.com>
To: Grygorii Strashko <grygorii.strashko@ti.com>,
Tero Kristo <t-kristo@ti.com>,
linux-omap@vger.kernel.org, linux-crypto@vger.kernel.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
tony@atomide.com
Cc: linux-arm-kernel@lists.infradead.org, lokeshvutla@ti.com
Subject: Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations
Date: Wed, 1 Jun 2016 18:03:52 -0500 [thread overview]
Message-ID: <574F69D8.1010809@ti.com> (raw)
In-Reply-To: <574EB091.6040001@ti.com>
On 06/01/2016 04:53 AM, Grygorii Strashko wrote:
> On 06/01/2016 11:56 AM, Tero Kristo wrote:
>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>
>> Calling runtime PM API for every block causes serious perf hit to
>> crypto operations that are done on a long buffer.
>> As crypto is performed on a page boundary, encrypting large buffers can
>> cause a series of crypto operations divided by page. The runtime PM API
>> is also called those many times.
>>
>> We call runtime_pm_get_sync only at beginning on the session (cra_init)
>> and runtime_pm_put at the end. This result in upto a 50% speedup.
>> This doesn't make the driver to keep the system awake as runtime get/put
>> is only called during a crypto session which completes usually quickly.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/crypto/omap-sham.c | 27 +++++++++++++++++----------
>> 1 file changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
>> index 6eefaa2..bd0258f 100644
>> --- a/drivers/crypto/omap-sham.c
>> +++ b/drivers/crypto/omap-sham.c
>> @@ -360,14 +360,6 @@ static void omap_sham_copy_ready_hash(struct
>> ahash_request *req)
>>
>> static int omap_sham_hw_init(struct omap_sham_dev *dd)
>> {
>> - int err;
>> -
>> - err = pm_runtime_get_sync(dd->dev);
>> - if (err < 0) {
>> - dev_err(dd->dev, "failed to get sync: %d\n", err);
>> - return err;
>> - }
>> -
Would it be worth it to investigate a pm_runtime autosuspend approach
rather than knocking runtime PM out here completely? I am not clear if
the overhead is coming from the pm_runtime calls themselves or the
actual idling of the IP, but if it's the idling of the IP causing the
slowdown, with a large enough autosuspend_delay we don't actually sleep
between each block but after a long enough period of idle time we would
actually suspend.
Regards,
Dave
>> if (!test_bit(FLAGS_INIT, &dd->flags)) {
>> set_bit(FLAGS_INIT, &dd->flags);
>> dd->err = 0;
>> @@ -999,8 +991,6 @@ static void omap_sham_finish_req(struct
>> ahash_request *req, int err)
>> dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) |
>> BIT(FLAGS_CPU) |
>> BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
>>
>> - pm_runtime_put(dd->dev);
>> -
>> if (req->base.complete)
>> req->base.complete(&req->base, err);
>>
>> @@ -1239,6 +1229,7 @@ static int omap_sham_cra_init_alg(struct
>> crypto_tfm *tfm, const char *alg_base)
>> {
>> struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
>> const char *alg_name = crypto_tfm_alg_name(tfm);
>> + struct omap_sham_dev *dd;
>>
>> /* Allocate a fallback and abort if it failed. */
>> tctx->fallback = crypto_alloc_shash(alg_name, 0,
>> @@ -1266,6 +1257,13 @@ static int omap_sham_cra_init_alg(struct
>> crypto_tfm *tfm, const char *alg_base)
>>
>> }
>>
>> + spin_lock_bh(&sham.lock);
>> + list_for_each_entry(dd, &sham.dev_list, list) {
>> + break;
>> + }
>> + spin_unlock_bh(&sham.lock);
>> +
>> + pm_runtime_get_sync(dd->dev);
>> return 0;
>> }
>>
>> @@ -1307,6 +1305,7 @@ static int omap_sham_cra_sha512_init(struct
>> crypto_tfm *tfm)
>> static void omap_sham_cra_exit(struct crypto_tfm *tfm)
>> {
>> struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
>> + struct omap_sham_dev *dd;
>>
>> crypto_free_shash(tctx->fallback);
>> tctx->fallback = NULL;
>> @@ -1315,6 +1314,14 @@ static void omap_sham_cra_exit(struct
>> crypto_tfm *tfm)
>> struct omap_sham_hmac_ctx *bctx = tctx->base;
>> crypto_free_shash(bctx->shash);
>> }
>> +
>> + spin_lock_bh(&sham.lock);
>> + list_for_each_entry(dd, &sham.dev_list, list) {
>> + break;
>> + }
>> + spin_unlock_bh(&sham.lock);
>> +
>> + pm_runtime_get_sync(dd->dev);
>
> May be put_?
>
>> }
>>
>> static struct ahash_alg algs_sha1_md5[] = {
>>
>
>
next prev parent reply other threads:[~2016-06-01 23:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 8:56 [PATCH 00/28] crypto: omap fixes / support additions Tero Kristo
2016-06-01 8:56 ` [PATCH 01/28] crypto: omap-aes: Fix registration of algorithms Tero Kristo
2016-06-07 10:48 ` Herbert Xu
2016-06-20 12:11 ` Tero Kristo
2016-06-20 23:49 ` Herbert Xu
2016-06-01 8:56 ` [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations Tero Kristo
2016-06-01 9:53 ` Grygorii Strashko
2016-06-01 23:03 ` Dave Gerlach [this message]
2016-06-07 10:08 ` Herbert Xu
2016-06-07 11:52 ` Tero Kristo
2016-06-07 12:24 ` Grygorii Strashko
2016-06-22 9:17 ` Tero Kristo
2016-06-01 8:56 ` [PATCH 03/28] crypto: omap-sham: change queue size from 1 to 10 Tero Kristo
2016-06-01 8:56 ` [PATCH 04/28] crypto: omap: do not call dmaengine_terminate_all Tero Kristo
2016-06-01 8:56 ` [PATCH 05/28] crypto: omap-sham: set sw fallback to 240 bytes Tero Kristo
2016-06-01 8:56 ` [PATCH 06/28] crypto: omap-sham: avoid executing tasklet where not needed Tero Kristo
2016-06-01 8:56 ` [PATCH 07/28] crypto: ahash: increase the maximum allowed statesize Tero Kristo
2016-06-01 8:56 ` [PATCH 08/28] crypto: omap-sham: implement context export/import APIs Tero Kristo
2016-06-01 8:56 ` [PATCH 09/28] crypto: omap-des: Fix support for unequal lengths Tero Kristo
2016-06-01 8:56 ` [PATCH 10/28] crypto: omap-aes - Fix enabling clocks Tero Kristo
2016-06-01 8:56 ` [PATCH 11/28] crypto: omap-aes: Add support for multiple cores Tero Kristo
2016-06-01 8:56 ` [PATCH 12/28] crypto: omap-aes: Add fallback support Tero Kristo
2016-06-01 8:56 ` [PATCH 13/28] crypto: engine: avoid unnecessary context switches Tero Kristo
2016-06-01 8:56 ` [PATCH 14/28] crypto: omap-aes: fix crypto engine initialization order Tero Kristo
2016-06-01 8:56 ` [PATCH 15/28] crypto: omap-des: " Tero Kristo
2016-06-01 9:04 ` [PATCH 16/28] ARM: DRA7: hwmod: Add data for DES IP Tero Kristo
2016-06-01 9:06 ` [PATCH 17/28] ARM: DRA7: hwmod: Add data for AES IP Tero Kristo
2016-06-01 9:06 ` [PATCH 18/28] ARM: DRA7: hwmod: Add data for SHA IP Tero Kristo
2016-06-01 9:06 ` [PATCH 20/28] ARM: OMAP: DRA7xx: Make L4SEC clock domain SWSUP only Tero Kristo
2016-06-01 9:06 ` [PATCH 21/28] ARM: AM43xx: hwmod: Add data for DES Tero Kristo
2016-06-01 9:06 ` [PATCH 22/28] ARM: AMx3xx: hwmod: Add data for RNG Tero Kristo
2016-06-01 9:06 ` [PATCH 23/28] ARM: dts: DRA7: Add DT node for DES IP Tero Kristo
2016-06-10 11:38 ` Tony Lindgren
2016-06-21 17:56 ` Tero Kristo
2016-06-22 7:58 ` Tony Lindgren
2016-06-01 9:06 ` [PATCH 24/28] ARM: dts: DRA7: Add DT nodes for AES IP Tero Kristo
2016-06-01 9:06 ` [PATCH 25/28] ARM: dts: DRA7: Add support for SHA IP Tero Kristo
2016-06-01 9:06 ` [PATCH 26/28] ARM: dts: DRA7: Add DT node for RNG IP Tero Kristo
2016-06-01 9:06 ` [PATCH 27/28] ARM: dts: AM43xx: clk: Add RNG clk node Tero Kristo
2016-06-01 9:06 ` [PATCH 28/28] ARM: dts: AM43xx: Add node for RNG Tero Kristo
2016-06-01 9:06 ` [PATCH 19/28] ARM: DRA7: hwmod: Add data for RNG IP Tero Kristo
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=574F69D8.1010809@ti.com \
--to=d-gerlach@ti.com \
--cc=davem@davemloft.net \
--cc=grygorii.strashko@ti.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).