Poul-Henning Kamp phk at phk.freebsd.dk
Thu Sep 12 13:15:43 CEST 2013

In message <5230A766.5040509 at schokola.de>, Nils Goroll writes:

>- private_oh->mtx now is a congestion point for all private object creation,
>   unbusy and deref

Maybe, maybe not.

It is trivial to loosen up that object, at the expense of (up to a
lot of) memory, but I want actual numbers to guide that tradeoff.

I think you should expect HSH_Private to stay, it is a pretty good
simplification of the code, and it helps make a lot of code simpler
(including vcl_err/synth)

One of the benefits of having a limited number of oh's for private
objects is for debugging:  We can now find them.  Previously they
had to be tracked down on some thread or other.

>Regarding the actual patch I am working on: [...]

First of all, we did agree that a successfull conditional fetch
should nuke the "old" object from cache, (ie: ignore obj.keep)
right ?

I expect that will solve most of the duplication problem ?

>HSH_Lookup when (oc->objhead == NULL) was still valid:
>- remove oc from oh while holding the oh->mtx anyway
>- NULL oc->objhead
>- EXP_Rearm outside oh->mtx
>- deref oh
>With HSH_Private, IIUC avoiding a second lock of oh->mtx is not possible any 
>more, so I wonder if HSH_Lookup sill would be the right place.

1. How could de-dup'ing a oh's list ever be relevant to pass/private
   objects ?  (ie: I don't understand what HSH_Private() changes for you.

2. I thought the way to do it was

   - spot duplicate
   - nuke its ttl,keep,grace and let EXP reap it

2. The three places I can see it happen are:
   a) HSH_Lookup
   b) HSH_Unbusy
   c) EXP

The reason I have pointed to HSH_Lookup() is that the code will
not affect pure hits, and the code to walk the list is there already.
In certain evironments this may still degenerate, so it has to be

A credible case can be made for Unbusy and EXP, but it will take
more code, since they don't traverse the list today.

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.

More information about the varnish-dev mailing list