[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130820182125.GA16741@openwall.com>
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.
