Commit Graph

4 Commits

Author SHA1 Message Date
Lukasz Szaszkiewicz 743b5776f9 storage/cacher/cache_watcher: add RV to watchCacheInterval
Kubernetes-commit: f87e4a19c88fa908eb176ee7925f211bafba9b45
2024-09-20 08:47:49 +02:00
Eric Lin 9cab6e4eee cacher: apply key for initial events
For case of SendInitialEvents, a buffer of objects is created. That
process takes a significant amount of memory and CPU when the resource
is of a large volume. Many objects may be not relevant when key is provided.
This commit applies key when composing the buffer for SendInitialEvents.

Signed-off-by: Eric Lin <exlin@google.com>

Kubernetes-commit: d9c6c8aa5047d724e0ebc8907f5fee4b10012ae3
2024-05-04 10:46:02 +00:00
Marek Siarkowicz cd751eb82e Implement conditionalProgressRequester that allows requesting watch progress notification if watch cache is not fresh
Kubernetes-commit: 98461be8ffa7383152c442414a16adb217e98080
2023-07-10 18:10:49 +02:00
Madhav Jivrajani 74fdb4a93b cacher: watchCacheInterval to reduce lock contention
watchCacheInterval serves as an abstraction over a source
of watchCacheEvents. It maintains a window of events over
an underlying source and these events can be served using
the exposed Next() API. The main intent for doing things
this way is to introduce an upper bound of memory usage
for starting a watch and reduce the maximum possible time
interval for which the lock would be held while events are
copied over.

The source of events for the interval is typically either
the watchCache circular buffer, if events being retrieved
need to be for resource versions > 0 or the underlying
implementation of Store, if resource version = 0.

Furthermore, an interval can be either valid or invalid at
any given point of time. The notion of validity makes sense
only in cases where the window of events in the underlying
source can change over time - i.e. for watchCache circular
buffer. When the circular buffer is full and an event needs
to be popped off, watchCache::startIndex is incremented. In
this case, an interval tracking that popped event is valid
only if it has already been copied to its internal buffer.
However, for efficiency we perform that lazily and we mark
an interval as invalid iff we need to copy events from the
watchCache and we end up needing events that have already
been popped off. This translates to the following condition:
  watchCacheInterval::startIndex >= watchCache::startIndex.
When this condition becomes false, the interval is no longer
valid and should not be used to retrieve and serve elements
from the underlying source.

Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>

Kubernetes-commit: 347607e97139959f33024a691d0561b1479aeeef
2021-12-05 23:17:00 +05:30