Re: 64-bit fun with cache.c

Laurent Bercot <[email protected]>
Newsgroups gmane.network.djbdns
Message-ID <[email protected]>
> 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.


> 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'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.

-- 
 Laurent
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.