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