[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3717df32c162418084cbf70e006892e@smtp.hushmail.com>
Date: Sun, 21 Jun 2015 02:10:56 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: ignore or limit Idle=Y for non-CPU-only?
On 2015-06-20 23:10, Solar Designer wrote:
> magnum - what do you think of the below? I think that for now we should
> simply make Idle=Y ignored when running OpenCL/CUDA formats, just like
> it is already ignored for OpenMP.
I'll have a look at implementing "ignore idle for GPU formats", in its
simplest form, but it'll be yet another case of using ugly
'strstr(fmt->params.label, "-opencl")' kludges since we don't have a
FMT_GPU flag. Maybe it's time we add one.
> On Tue, Jun 02, 2015 at 03:56:14AM +0300, Solar Designer wrote:
>> There's another aspect here, though. When targeting NVIDIA GPUs, we
>> often end up having a thread busily looping on the CPU.
>> So to avoid wasting that CPU core for potential concurrent CPU-using
>> instances of john, maybe we can check if the target device is an NVIDIA
>> card and if so only partially ignore Idle=Y: do invoke nice(20), but
>> don't use SCHED_IDLE and don't invoke sched_yield(). Unfortunately,
>> this would still cause some reduction in GPU usage when there's a
>> concurrent CPU-using john - just not as much reduction as the current
>> idle.c code causes.
I'll see if I can tuck this in too.
>> Or maybe we need to make Idle tri-state? If so, what exactly would the
>> three states correspond to?
Like Yes/No/Auto? This is beyond most users so I think we should sort it
out automagically. At least until someone complains our best-effort
logic causes trouble.
magnum
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.
