[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110511013906.GA9245@openwall.com>
Date: Wed, 11 May 2011 05:39:06 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: single mode problem
On Tue, May 10, 2011 at 08:00:45PM -0500, jfoug wrote:
> But this may be along the same line. It might also work, to create a
> 'named' mem_alloc_tiny pool allocator. Then a set of work could own it's
> own allocation pool, and when done with it, simply release the entire pool.
> There would be the default 'global' poop we have today with mem_alloc_tiny,
> but add another mem_alloc_named(name,size,align) along with a
> free_alloc_name(name), and possibly mem_alloc_named_setup(name,blocksz).
> Hash the name, and it should be pretty fast, but would allow having your own
> localized tiny aligned memory allocator. It could even speed things up, by
> reducing the working set for some formats.
Yes, I was thinking of something similar, except that I think the "name"
should be a pointer to some struct with basic info on the pool. The
struct itself may be static or it may be on stack in a function that
needs a memory pool for its own use only.
And we can have two global pools - a hot and a cold one. The hot one
will contain binary hashes (or partial hashes), hash tables, etc. The
cold one will be used for things such as usernames and source
representations of hashes.
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.
