diff options
author | Ayush Ranjan <ayushranjan@google.com> | 2021-04-20 13:36:56 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2021-04-20 13:38:50 -0700 |
commit | 07a78ecb2918905af030a8cf81ee86ddd1c622c5 (patch) | |
tree | 4fd96d931a2f20055c277ffc1dacb1903be66c91 /test/perf | |
parent | 8192cccda61d84f6caaf0a37ee3ba41cb6c4826c (diff) |
[perf] Remove non-empty directory dentries from gofer LRU cache.
The gofer client's LRU cache has a default limit of 1000 dentries. Any attempt
to cache more dentries than that will make the LRU cache evict and destroy the
least recently used dentry. However, the eviction is expensive because it
requires holding fs.renameMu for writing - which in turn creates a lot of
contention. All filesystem operations that involve path traversal require
fs.renameMu for reading atleast.
Therefore, it is in our best interest to keep the cache small and clean.
When a dentry is inserted in the dentry tree, it grabs a ref on its parent for
its entire lifetime. Hence the parent is longer evictable (because refs > 0).
This change additionally calls checkCachingLocked on directories that have been
added to so that they can be removed from the LRU cache if needed.
This change implies that the LRU cache will only contain the leaves from the
filesystem tree which significantly reduces the LRU cache size and consequently
reduces the number of expensive LRU cache evictions.
> Why are opened dentries not removed from LRU cache?
When a file description is open(2)-ed, the file description holds a ref on its
dentry for its entire lifetime. However, calling checkCachingLocked() on opened
dentries actually ends up hurting performance. Applications usually open file
descriptors for a short duration. So upon close(2), the dentry is reinserted
into the cache anyway. So the precautionary work done in removing the opened
dentry from the cache went for waste as it did not really reduce an eviction.
Local benchmarking has shown that this change improves performance by 3-4%.
Across 6 runs, without this change it took 296.127 seconds to build runsc while
with this change it took only 285.136 seconds.
PiperOrigin-RevId: 369510494
Diffstat (limited to 'test/perf')
0 files changed, 0 insertions, 0 deletions