> Von: Scott Wood [scottw...@freescale.com]
> Gesendet: Dienstag, 20. Januar 2015 08:38
> An: Markus Stockhausen
> Cc: Michael Ellerman; linuxppc-dev@lists.ozlabs.org
> Betreff: Re: AW: How to make use of SPE instructions?
> ...
> > I did some tests with the tcrypt module and I get a hashing speed of
> > ~ 46MByte/s for 2K data chunks. Stock module gives 29MByte/s. In
> > other words ~22,000 hashes per second. Overhead of the tcrypt data
> > feeder of around 10% included. That are worst case 46us per hash and
> > therefore 46us inside a non preemptive task.
> ...
> It's OK if the worst case is really 46 us, but if you can find a way to
> break it up a bit without affecting throughput too much, I'd do so.
Hi Scott (and all),
with your answer I'm a bit confused about disabling preemption inside the
kernel right now. I understand that the interval between preempt_disable()
and preempt_enable() should not take too long. But when I look at other
kernel hash crypto modules I see that nobody really cares about that. Take
sha256_ssse3_update() in sha256_ssse3_glue.c for example. It runs
kernel_fpu_begin();
res = __sha256_ssse3_update(desc, data, len, partial);
kernel_fpu_end();
The kernel_fpu_xxx() enables/disables preemption like I need to do.
Nevertheless parameter len can be any number of bytes. Just take
reasonable parameters of 256K of input data, a 3GHz core and 13
cycles/byte of SHA256 throughput. That will be a 1ms timeframe.
Can I rely on that implementation, or do I have to take special care
because I'm only programming for a single core CPU?
With your advice I would place a enable/disable preemption call after
1K of processed data. But wil that be sufficient if I only reeanble it
for a short timeframe like this:
do {
disable_preemption()
... calc hashes for 1K of data with 16.000 CPU cycles (or 20us) ...
enable_preemption()
while (dataleft>0);
Markus
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Ãber das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
