benchmarks sensitive to disk IO using base::EvictFileFromSystemCache() without waiting for eviction |
|||
Issue descriptionOn Linux/Android the base::EvictFileFromSystemCache() calls posix_fadvise(DONTNEED) and returns immediately. Since posix_fadvise removes the physical pages asynchronously, this operation does not guarantee that the pagecache for the file is evicted. Kudos to lizeb@ for noticing this! I see a few uses of this method: * visitedlink_perftest.cc (was like that since the initial.commit) * disk_cache_perftest.cc * clear_system_cache_main.cc (used in Telemetry for various benchmarks) lizeb@ is suggesting an unscientific solution to this to sleep(2), which I .. like! (here: https://chromium-review.googlesource.com/c/chromium/src/+/1116700) For a 'more scientific approach' we would need to poll mmap+mincore or /proc/pid/pagemap. More ideas are welcome before we go with any of these verbose approaches.
,
Jun 27 2018
I think I actually noticed this with the Windows version, FWIW.
,
Sep 13
,
Sep 17
Two things were introduced: sync() before dropping the pagecache and sleep() afterwards, which increased time to do 'coldish' starts (seems to make them more realistic). It did not reduce the noise a lot, probably masked by other sources. Another idea how to make pagecache eviction better is from mattcary@. If I understood correctly, it is to evict all pagecache (echo 3 >/proc/sys/vm/drop_caches) followed by starting an app that is not Chrome, to warm up a bit of Framework/services parts. I think that'd be interesting to compare the two approaches. Maintaining an app that covers enough to 'Eliminate disk accesses outside Chrome' looks more complicated than dropping caches from a few select directories. Not taking this approach now.
,
Sep 17
That's my idea, yes. For posterity, the specific motivation is that we noticed the coldish starts did not evict much of the native library, causing its prefetch to take a short amount of time. The problem there is that prevents the benchmark from seeing if there has been a regression in native library prefetching. However, especially for monochrome apps, it may be the case in practice that much of the native library is in core, and so the short prefetch time is actually realistic. This also also implies that prefetch may not be as necessary as it once was. In summary: if we want to track how prefetch is doing, evicting all pagecache + simple app seems like it would do the trick. If we want realism... then we're not sure. The place to start, perhaps, is to eyeball LibraryLoader.PercentageOfResidentCodeBeforePrefetch.
,
Sep 17
Thanks! > we noticed the coldish starts did not evict much of the native library that's better now than it was a few days ago. With health-plan-clankium-phone and perf-go-phone-1024 we see that eviction is at least doing something: https://chromeperf.appspot.com/report?sid=fb2fd44a0c3cb14cd0f969027f84a0a50ea696f57c57e5f3dd0dc990b78e89c8 And as per crbug.com/881384#c9 we see that health-plan-clankium-phone (N5) takes 400-500ms in asyncPrefetchLibrariesToMemory, which is what we generally expect. One remaining problem is the monochrome badness: crbug.com/881384#c14 (perhaps the directory is detected incorrectly, praying for it). Will investigate shortly. |
|||
►
Sign in to add a comment |
|||
Comment 1 by pasko@chromium.org
, Jun 27 2018