summaryrefslogtreecommitdiffhomepage
path: root/test/packetimpact/dut
diff options
context:
space:
mode:
authorAyush Ranjan <ayushranjan@google.com>2021-04-20 13:36:56 -0700
committergVisor bot <gvisor-bot@google.com>2021-04-20 13:38:50 -0700
commit07a78ecb2918905af030a8cf81ee86ddd1c622c5 (patch)
tree4fd96d931a2f20055c277ffc1dacb1903be66c91 /test/packetimpact/dut
parent8192cccda61d84f6caaf0a37ee3ba41cb6c4826c (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/packetimpact/dut')
0 files changed, 0 insertions, 0 deletions