Content-Disposition: inline
Message-ID: <20171017180537.GA25723@jurassic>
References: <RT-Ticket-46307@isc.org> <20171017173731.GA5372@jurassic> <rt-4.4.1-41896-1508261864-1480.46307-3-0@isc.org>
content-type: text/plain; charset="utf-8"
In-Reply-To: <rt-4.4.1-41896-1508261864-1480.46307-3-0@isc.org>
Subject: Re: [ISC-Bugs #46307] Some LRU tweaks for negative rdatasetheader handling
User-Agent: Mutt/1.9.1 (2017-09-22)
From muks@isc.org  Tue Oct 17 18:05:46 2017
Date: Tue, 17 Oct 2017 23:35:37 +0530
X-RT-Incoming-Encryption: Not encrypted
From: "Mukund Sivaraman" <muks@isc.org>
MIME-Version: 1.0
To: "Mukund Sivaraman via RT" <bind9-public@isc.org>
RT-Message-ID: <rt-4.4.1-41896-1508263550-328.46307-0-0@isc.org>
Content-Length: 836

On Tue, Oct 17, 2017 at 05:37:44PM +0000, Mukund Sivaraman via RT wrote:
> We can also remove this second part if we want to be strict - i.e., just
> let all negative answers get cleaned up first whether they have been
> recently used or not.

I decided to implement this in rt46307. It's easier to implement, is
more stricter. If someone actually complains that it affects performance
badly, then we can look at it.

So basically NEGATIVE is handled the same as ZEROTTL. It's always left
towards the end of the LRU where it'll be swept first.

There's a slight chance that a cache is overmem, and a negative answer
that was just fetched is deleted from cache quickly (before it can be
used to answer any additional queries). But an overmem situation doesn't
last continuously, so this ought not to be a performance problem.

		Mukund