Re: 64-bit fun with cache.c

On Fri, Jan 23, 2009 at 1:17 AM, Laurent Bercot <[email protected]> wrote:
>> Has anybody successfully hacked cache.c for 64-bit operation?  I'm
>> screwing around with this now:
>
>  Are you sure you want more than 4 GB of cache ?
>  Have you profiled how much you would gain from such a big cache ?
>  4 GB is already huge.

4 GB ought to be enough for everybody, eh?

I've never run djbdns on anything other than a small private network.
I never changed the cache size.  However:

http://marc.info/?l=djbdns&m=117057828528479&w=2

To quote Jeremy Kister : "I have a need to run dnscache with more than
4GB memory."

I don't know whether he really needed a cache that big or if he just
thought he did.  I don't really care.  I think somebody with 64-bit
hardware and > 4GB of RAM should be able to take advantage of it
without hacking the source.

>> I'm wondering how much of performance hit this would be on 32-bit
>> systems.  I don't want to screw around with trying to detect whether
>> the build platform is 32-bit or 64-bit.
>
>  tryulong64.c does it for you.
>  If you have uint64.h2, i.e. your unsigned long is 64 bit, chances
> are your build platform is natively 64-bit. If you have uint64.h1, i.e.
> you have to write "unsigned long long" to get a 64-bit type, chances
> are your build platform is NOT natively 64-bit.

I tossed tryulong64.c in favor of an autoconf macro: AC_TYPE_UINT64_T.
 I can, via various mechanisms, arrange for various variables and
return types to be uint32 or uint64 depending on the platform.  I
don't know that I care to.  I can just declare them uint64 and let
autoconf and the compiler sort it all out.  Unless there is a
significant performance hit on a 32-bit platform trying to index into
a dynamically allocated character array via a long long index, I'm
just going to declare uint64 and drive on.  I may just compile a test
program and disassemble it and see what the compiler ends up
generating.  If it's not too ugly, I'm not going to worry about it.
I've seen reports that 64-bit multiplication on platforms with no
64-bit registers can be up to 12 times slower.  Addition shouldn't be
that bad.  At the instruction level, all that should be happening is
incrementing a base memory address via addition.  The offset is 64-bit
instead of 32-bit.  The compiler might optimize it all away.  Any
insight appreciated.

>> I'm toying around with the idea of eliminating the cachesize limit
>> altogether, though I wonder if some limit isn't in order to keep
>> somebody from fat fingering the requested size and immediately
>> thrashing the machine into the ground.
>
>  You are wise in wondering. A fixed cache limit is part of what
> makes djbdns safe; it protects the machine from DoS based on
> malicious requests, it allows the administrator total control
> over the amount of memory dnscache will be using.
>  The CACHESIZE variable is one of the fundamental design decisions
> in djbdns that make it so superior to BIND. Do not fiddle with it
> without understanding why it was put there in the first place.

I'm talking about the hardcoded *limit* for the cachesize.  The actual
size is determined at run time and does not grow, but stock djbdns
ships with a limit fixed at compile time as to how big the cache can
be.  If you request more than the limit, you get the limit, not what
you asked for.  If I remove that hardcoded limit, the cachesize is
still fixed at run time to a static size.