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
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)
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:
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