ban lurker questions

Nils Goroll slink at schokola.de
Fri Apr 15 17:44:14 CEST 2016


Hi,

I am working on a ban (lurker) performance issue, which, at this point, is
simply caused by too frequent and too inefficient bans - but anyway, I'd like to
understand the code to the best of my abilities.

1) ban_cleantail

why do we acquire the mtx for every ban we look at rather than collecting all
the bans to be freed in a loop while holding the mtx?

2) would this assertion be correct?

diff --git a/bin/varnishd/cache/cache_ban_lurker.c
b/bin/varnishd/cache/cache_ban_lurker.c
index 65c552e..fb69f78 100644
--- a/bin/varnishd/cache/cache_ban_lurker.c
+++ b/bin/varnishd/cache/cache_ban_lurker.c
@@ -190,6 +190,7 @@ ban_lurker_test_ban(struct worker *wrk, struct vsl_log *vsl,
struct ban *bt,
                        VSC_C_main->bans_lurker_obj_killed++;
                } else {
                        if (oc->ban != bd) {
+                               assert(oc->ban == bt);
                                Lck_Lock(&ban_mtx);
                                oc->ban->refcount--;
                                VTAILQ_REMOVE(&oc->ban->objcore, oc, ban_list);


3) ban_lurker_getfirst questions:

- for the contention case, shouldn't we continue walking the bt->objcore list
  and sleep only if we hit the marker?

  instead of sleeping, we could make progress on other objheads, and chances
  are that we've got more luck next time.

- do IUC correctly that getfirst moves the oc to the tail of the bt->objcore
  list, behind the marker, to ensure we don't re-visit ocs which have not got
  killed yet, after being handed off to exp?

4) ban_lurker_work

why do we mark_completed and then clean out the completed bans in the next step
rather than removing the completed bans straight away? Why do we need to do the
spec fiddling in ban_mark_completed (including a membar (!)) if we're about to
ditch the ban anyway?

Danke, Nils



More information about the varnish-dev mailing list