[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scrypt 1.3.0 released

On Wed, Jan 01, 2020 at 11:02:29PM -0500, Ted Unangst wrote:
> Colin Percival wrote:
> > * When estimating the amount of available RAM, scrypt ignores RLIMIT_DATA on
> >   systems which have mmap.
> I'm a bit late here, but this is the wrong thing to do for OpenBSD. On
> OpenBSD, rlimit_data is applied to anonymous mmap (since that's now the heap)
> for consistency. RLIMIT_RSS is a vestigal do nothing define.

I don't have an opinion about whether or not it's the right thing to do, but
here's a bit more info for context.

The RLIMIT_DATA change was prompted by NetBSD, which set it to 512 MiB and
argued that this limit shouldn't be interpreted as applying to mmap.  The
precise change, along with commit message, is:

Empirically, I can't see any problem with OpenBSD 6.4.  I tested it inside
virtualbox with 1024 and 2048 MiB of ram, compiled with -DDEBUG, and the
output looks reasonable.  For example with 2048 MiB, I get:

openbsd-64$ ./scrypt enc -v config.h foo.enc                                   
Please enter passphrase: 
Please confirm passphrase: 
Memory limits are:
        usermem:        18446744073709551615
        memsize:        18446744073709551615
        sysinfo:        18446744073709551615
        rlimit:         2055176192
        sysconf:        2130640896
** smallest:            2055176192
** after frac:          256897024
** after specified:     256897024
Allowing up to 256897024 memory to be used
Clock resolution is 0.01
47104 salsa20/8 cores performed in 0.010069 seconds
Requiring 128Nr <= 256897024, 4Nrp <= 23390604.826696
Parameters used: N = 131072; r = 8; p = 5;
    This requires at least 134 MB bytes of memory (256 MB available),
    and will take approximately 0.6 seconds (limit: 5.0 seconds).

(I added the "**" lines just to double-check exactly what was happening,
because I'd forgotten that our default "memory fraction" is 0.125.)

- Graham