|
Message-ID: <20150901203604.GA19363@openwall.com> 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.