In message <[email protected]>, 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 cheap. 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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
