HSH_Private

[Poul-Henning Kamp]

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
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
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.