Hi GaoKui,
On Thu, Jul 26, 2018 at 02:44:30AM +, gaokui (A) wrote:
> Hi, Eric,
> Thanks for your reply.
>
> I have run your program on an original kernel and it reproduced the
> crash. And I also run the program on a kernel with our patch, but there was
> no crash.
>
>
Hi, Eric,
Thanks for your reply.
I have run your program on an original kernel and it reproduced the
crash. And I also run the program on a kernel with our patch, but there was no
crash.
I think the reason of the crash is the parameter buffer is aligned
with the
On 25 July 2018 at 03:29, Eric Biggers wrote:
> From: Eric Biggers
>
> The 4-way ChaCha20 NEON code implements 16-bit rotates with vrev32.16,
> but the one-way code (used on remainder blocks) implements it with
> vshl + vsri, which is slower. Switch the one-way code to vrev32.16 too.
>
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, July 24, 2018 10:42 PM
> To: linux-crypto@vger.kernel.org
> Cc: herb...@gondor.apana.org.au; will.dea...@arm.com;
> dave.mar...@arm.com; Vakul Garg ;
> bige...@linutronix.de; Ard Biesheuvel
On 2018-07-25 06:57:42 [+], Vakul Garg wrote:
> I tested this patch. It helped but didn't regain the performance to previous
> level.
> Are there more files remaining to be fixed? (In your original patch series
> for adding
> preemptability check, there were lot more files changed than this
> -Original Message-
> From: bige...@linutronix.de [mailto:bige...@linutronix.de]
> Sent: Wednesday, July 25, 2018 12:33 PM
> To: Vakul Garg
> Cc: Ard Biesheuvel ; linux-
> cry...@vger.kernel.org; herb...@gondor.apana.org.au;
> will.dea...@arm.com; dave.mar...@arm.com
> Subject: Re:
On 2018-07-25 07:04:55 [+], Vakul Garg wrote:
> >
> > What about PREEMPT_NONE (server)?
>
> Why not have best of both the worlds :)
the NEON code gets interrupted because another tasks wants to schedule
and the scheduler allows. With "low latency desktop" this gets right
done away. The
On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
> In preparing to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
> the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
> to direct shash. By removing a
(+ Mark)
On 25 July 2018 at 08:57, Vakul Garg wrote:
>
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, July 24, 2018 10:42 PM
>> To: linux-crypto@vger.kernel.org
>> Cc: herb...@gondor.apana.org.au; will.dea...@arm.com;
>>
On 25 July 2018 at 09:27, Ard Biesheuvel wrote:
> (+ Mark)
>
> On 25 July 2018 at 08:57, Vakul Garg wrote:
>>
>>
>>> -Original Message-
>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>> Sent: Tuesday, July 24, 2018 10:42 PM
>>> To: linux-crypto@vger.kernel.org
>>> Cc:
On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
> iteration of the GHASH and AES-GCM core routines is having a considerable
> performance impact on cores such as the Cortex-A53 with Crypto Extensions
>
On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
> Vakul reports a considerable performance hit when running the accelerated
> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
> been updated to take the TIF_NEED_RESCHED flag into account.
>
> The issue
On 25 July 2018 at 11:05, Dave Martin wrote:
> On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
>> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
>> iteration of the GHASH and AES-GCM core routines is having a considerable
>> performance impact on cores such
On 25 July 2018 at 11:09, Dave Martin wrote:
> On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
>> Vakul reports a considerable performance hit when running the accelerated
>> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
>> been updated to take the
On Wed, Jul 25, 2018 at 10:23:00AM +0100, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:09, Dave Martin wrote:
> > On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
> >> Vakul reports a considerable performance hit when running the accelerated
> >> arm64 crypto routines with
On Wed, Jul 25, 2018 at 10:11:42AM +0100, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:05, Dave Martin wrote:
> > On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
> >> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
> >> iteration of the GHASH and AES-GCM core
On 25 July 2018 at 11:48, Dave Martin wrote:
> On Wed, Jul 25, 2018 at 10:11:42AM +0100, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:05, Dave Martin wrote:
>> > On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
>> >> As reported by Vakul, checking the TIF_NEED_RESCHED flag after
On 25 July 2018 at 11:45, Dave Martin wrote:
> On Wed, Jul 25, 2018 at 10:23:00AM +0100, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:09, Dave Martin wrote:
>> > On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
>> >> Vakul reports a considerable performance hit when running the
On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm has
tools/perf/tests/.gitignore:
LLVM byte-codes, uncompressed
On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
wrote:
> On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
>
>> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
>> > On Tue, 24 Jul 2018 13:13:25
On Wed, 2018-07-25 at 15:12 +0200, Arnd Bergmann wrote:
> tools/perf/tests/.gitignore:
> LLVM byte-codes, uncompressed
> On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
> wrote:
> > On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
> >
> > > On Tue, 2018-07-24 at
On 2018-07-25 11:54:53 [+0200], Ard Biesheuvel wrote:
> Indeed. OTOH, if the -rt people (Sebastian?) turn up and say that a
> 1000 cycle limit to the quantum of work performed with preemption
> disabled is unreasonably low, we can increase the yield block counts
> and approach the optimal numbers
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash directly and allocating the
23 matches
Mail list logo
