Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Aug 2013 22:21:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt

Katja,

On Tue, Aug 20, 2013 at 09:59:26PM +0400, Solar Designer wrote:
> When you use e_write(), does it go through host CPU's caches?  Can
> e_read() possibly read from there?  Even if not caches, then perhaps at
> least write buffers.
> 
> In epiphany-hal.c functions ee_write*() and ee_read*(), we ultimately
> write and read, respectively, using host's address space, and there's no
> indication that these addresses would somehow be excluded from caching
> on the host (our ARM CPU _does_ have caches, unlike Epiphany).  I guess
> the CPU can commit those cache lines to external memory any time it
> likes, and not necessarily in order.  Similarly, its write buffers might
> not be committed (to L2 cache?) right away and in order.

BTW, it appears that our L2 cache is in write-back mode by default
(faster, but likely exacerbates the problem for us):

http://www.zedboard.org/content/changing-cache-policy-arm-zynq

No, I am _not_ suggesting to play with cache settings, crippling our
host CPU just to workaround the problem.  We ought to solve it for real,
while keeping write-back caching on host enabled.

(Well, Parallella system designers may choose to exclude a certain
address range from caching, if that is supported.  But that's not our
call to make.)

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.