git-svn-id: http://www.varnish-cache.org/svn/trunk@2538 d4fa192b-c00b-0410-8231-f00ffab90ce4

the LRU list and the binary heap.  In both of these cases, operations
on one object will result in certain fields in neighbor objects in
these data structures to be updated.

In difference from cache_hash.c which examine objects related by
hash match where the existence of the hash lookup in the first place
is a predictor for their likely use, in cache_expire the neighbor
objects are totally unrelated and the fact that we update their
list pointers or binheap index in no way indicates that they will
get a cache hit any time soon.

Paging in one page for a number of objects, just to move another
object up or down the binheap or LRU list is thus not only slow,
but also increases varnish' VM footprint for no real benefit.

This commit moves the relevant housekeeping fields into a "objexp"
structure, which gets hung off the objects when they enter the cache.

The objexp structure is small (40 bytes on i386) so statistically it
is more than an order of magnitude more likely to already be in core
when we need it, compared to the object itself.




git-svn-id: http://www.varnish-cache.org/svn/trunk@2537 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2536 d4fa192b-c00b-0410-8231-f00ffab90ce4

when we shuffle the LRU list.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2535 d4fa192b-c00b-0410-8231-f00ffab90ce4

expiry mutex without waiting.

This is in addition to the already present "only if it have not
been moved recently" check.

This additional mutex-contestion reduction obviously might leave
the LRU list badly out of order, but this can be worked around
by examining obj.last_use in vcl_discard()



git-svn-id: http://www.varnish-cache.org/svn/trunk@2534 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2533 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2532 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2531 d4fa192b-c00b-0410-8231-f00ffab90ce4

cache_expire.c.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2530 d4fa192b-c00b-0410-8231-f00ffab90ce4

pool shortages.

Fixes ticket #213


git-svn-id: http://www.varnish-cache.org/svn/trunk@2529 d4fa192b-c00b-0410-8231-f00ffab90ce4

first, then /dev/random, then fall back to pid and time.  Using an
uninitialized stack variable as seed is just silly, and Coverity rightly
complains about it (CID#19)


git-svn-id: http://www.varnish-cache.org/svn/trunk@2528 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2527 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2526 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2525 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2521 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2520 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2519 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2518 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2517 d4fa192b-c00b-0410-8231-f00ffab90ce4

HSH_Lookup() is supposed to guarantee this, but it appears that it
sometimes doesn't (perhaps a bug snuck in with grace mode?)


git-svn-id: http://www.varnish-cache.org/svn/trunk@2516 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2515 d4fa192b-c00b-0410-8231-f00ffab90ce4

Use EV_ONESHOT for all session events to make the kernel delete the
event when it fires, to remove any chance of any race with session
state and kqueue event arming.

For sessions with acceptfilter, this does just what we want (and I
kick myself for not realizing this much sooner).

For sessions where the acceptfilter is not enabled or has given up,
this results in an extra kevent arming operation for each read, but
this is still a much lower overhead than synchrnously deleting
the event when before passing the session on.

Delete all the workarounds and band-aids that had accumulated.

All in all, a win-win-win situation.

I have no idea how many tickets this will close.



git-svn-id: http://www.varnish-cache.org/svn/trunk@2514 d4fa192b-c00b-0410-8231-f00ffab90ce4

on a session that no longer has the fd that the event was registered on.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2513 d4fa192b-c00b-0410-8231-f00ffab90ce4

#ifdef, which we retain for really heavy duty instrumentation, should
we ever need that.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2512 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2511 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2510 d4fa192b-c00b-0410-8231-f00ffab90ce4

instead of #ifdef DIAGNOSTICS for control.

Also reduce VSL mutex cost by 50% for the common case where we have
a worker thread: We did a WSL_Flush() followed by a VSL(), doing a
WSL() before the WSL_FLush saves one VSL mutex op.




git-svn-id: http://www.varnish-cache.org/svn/trunk@2509 d4fa192b-c00b-0410-8231-f00ffab90ce4

us, instead of the #ifdef DIAGNOSTICS which is always not there when you
need it or there when you don't want it.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2508 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2507 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2506 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2505 d4fa192b-c00b-0410-8231-f00ffab90ce4

Also, clean up some variable names and declarations.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2502 d4fa192b-c00b-0410-8231-f00ffab90ce4

 - modify thread_log() to take an "errcode" argument (typically errno) so
   we don't have to sprinkle the code with strerror() calls.

 - read_line() and read_block() would sometimes unnecessarily log an error
   for a short read; let the caller decide whether a short read is
   acceptable.

 - reorder the if / else if / else blocks in receive_response() so the
   logic is easier to follow.

 - remove test code which we no longer need.

 - fix some style issues; there are still a couple of long lines, though.


git-svn-id: http://www.varnish-cache.org/svn/trunk@2501 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2500 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2499 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2498 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2497 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2494 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2493 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk@2492 d4fa192b-c00b-0410-8231-f00ffab90ce4