[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <887AE7BB-1C63-4267-BB22-7BA71CF3E85A@gmail.com>
Date: Tue, 17 Mar 2015 17:38:38 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC
Hi,
I reran the benchmarks on MIC, with or without OpenMP, and got some statistics.
With OpenMP:
The result is a bit different from last time. The program didn't get killed when running mschapv2-naive, but aborted later when running mysql, with error message: *****mem_alloc(): Cannot allocate memory trying to allocate 5190451200 bytes*****
I also monitored the memory usage when running the benchmarks. The free memory space floated between 3GB to 6GB during the benchmark, and it's over 3GB when the program aborted.
In total, it ran through 195 tests, 80 of which FAILED.
Without OpenMP:
With OpenMP disabled, the program survived all the tests. The memory usage is also lighter, floating between 5GB to 6GB.
In total, it ran through 294 tests, 126 of which FAILED.
Comparison:
Both versions share the same list of failed tests (except for those that the OpenMP-enabled version didn't survive to see). The attached files include the output of the benchmarks, and list of failed tests. The '-nomp' suffix indicates the OpenMP-disabled version.
Which issue should I focus on first? The FAILED tests or those memory hogs?
Appreciation for advices.
Lei
> On Mar 16, 2015, at 2:14 AM, Solar Designer <solar@...nwall.com> wrote:
>
> On Sun, Mar 15, 2015 at 01:12:48PM +0800, Lei Zhang wrote:
>> I fixed the configuration problem and descrypt behaves normally now.
>>
>> And after deleting some files, we now have over 6GB free memory space on our MIC card. Thanks to that, scrypt can run now.
>
> Great.
>
>> This time john-jumbo ran through a bunch of benchmarks, some of which FAILED although.
>
> There are probably bugs for you to find and fix for those. While this
> won't matter much for actually running them on MIC - this is scalar code
> currently, and you'd need to switch it to MIC intrinsics later - it may
> matter for other uses of the same code, on other platforms. We don't
> want bugs sitting in there, waiting to bite someone else.
>
> One way to focus your search for bugs is to make and run a non-OpenMP
> build as well. Then see which formats fail self-test in both builds vs.
> in just one (and which one). While this won't provide conclusive
> results, it may provide clues and let you focus your search.
>
>> It got killed again when running smchapv2-naive. I guess it ran out of memory again?
>
> Perhaps. Can you try running the mschapv2-naive self-test on its own,
> not along with the rest? Something like:
>
> ./john --test --format=mschapv2-naive
>
> If it runs fine, then the problem was likely caused by memory allocation
> by the formats that were tested previously. Some of them intentionally
> allocate memory such that it can't be freed. This lowers overhead for
> when john is run for cracking, with just one specific format, but it
> results in increased total memory usage for a many-formats self-test.
> We should only be making such non-freed allocations for things that are
> small. For larger allocations, formats should free the memory in their
> done() methods. Perhaps some formats allocate "too much" memory (at
> least when the number of threads is this large) and don't free it - and
> perhaps you should identify them and change them to free the memory.
> You can watch memory usage as the self-tests are running to identify
> roughly when (at which format) the memory usage (or the remaining free
> memory) changes rapidly. You may use e.g.:
>
> [user@...er-mic0 user]$ while :; do free | grep '^-/+ buffers'; sleep 1; done
> -/+ buffers: 449172 7433144
> -/+ buffers: 449080 7433236
> -/+ buffers: 448780 7433536
>
>> The output is a bit lengthy this time. So I put them in a text file attached below. Please see for yourself.
>
> Yes, thanks!
>
> This also shows that django-scrypt is somehow much slower than the main
> scrypt format. That's unexpected. But we need to merged them anyway.
>
> Alexander
Content of type "text/html" skipped
Download attachment "jumbo-log" of type "application/octet-stream" (26458 bytes)
Content of type "text/html" skipped
Download attachment "jumbo-log-nomp" of type "application/octet-stream" (34449 bytes)
Content of type "text/html" skipped
Download attachment "jumbo-failed" of type "application/octet-stream" (844 bytes)
Content of type "text/html" skipped
Download attachment "jumbo-failed-nomp" of type "application/octet-stream" (1222 bytes)
Content of type "text/html" skipped
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.
