[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 1 Sep 2015 23:36:04 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: -dev=... -fork=... wastes GPU memory
On Fri, Aug 28, 2015 at 01:41:08AM +0200, magnum wrote:
> On 2015-08-28 01:21, magnum wrote:
> >I had a look. We take care not to do *anyhing* OpenCL prior to forking.
> >Any such stuff is post-poned. Then right after forking, we enumerate
> >cards and pick one just as if each child was a single process.
> >
> >This made me think that the exact same thing will happen with just a
> >single process, but I just checked and apparently it isn't. Very
> >strange. I need to let this grow for a while.
>
> I found this now by pure coincidence:
> http://www.openwall.com/lists/john-dev/2013/07/02/11 (very long thread,
> several branches).
>
> Sounds a lot like a variant of the same problem. However, we did change
> a lot of stuff (eg. we're not initializing OpenCL at all for CPU
> formats, and never prior to forking).
Yet another aspect of the problem:
Today, I was stress-testing super (after the recent hardware changes) by
running "-fork=5 -dev=1,2,6,7,0" - that is, targeting all GPUs, but not
CPUs and not Xeon Phi. This resulted in my Xeon Phi native OpenMP
benchmarks slowing down considerably. It turned out that the process
responsible for OpenMP offload and for OpenCL on Xeon Phi was warmed up,
eating up one core. Manually reducing my native OpenMP thread count
from 240 to 236 has helped. Yet 240 is optimal when there isn't a john
running on the host and talking to the GPUs.
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.
