ban_lurker_age, ban_lurker_sleep

[Poul-Henning Kamp]

--------
In message <57152FD8.8090705 at schokola.de>, Nils Goroll writes:

>This probably is the scenratio which is most relevant for cases of good use of
>the ban lurker. The case I'm working on is 40k expensive bans on 400k objects
>when the ban luker cannot keep up for long periods of time (yes, I know this is
>bad use of bans, but still an intersting case).
>
>With such numbers of bans, avoiding ban tests at lookup time should be
>relevant, so kicking in the lurker early should help.

Well, depends what you want helped I guess :-)

Either way, that's why it is a parameter, I'm sure there's no one size
that fits everybody.

>As long as the ban lurker is single threaded, it's pretty hard rate-limited
>already on any real-life system of relevance.

Not really, there are many systems where the full attention of the
ban lurker is undesirable.

For instance a system with a gazillion objects where a single ban
is used to take out a handful of objects because of some one-off
mistake.

In that scenario it is much better to let the req-time validations do
the job, than having the lurker go full tilt and page in the entire
cache.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.