The current xperf talos seems to include FileFlush in the count, but it doesn't add that to the output. Would be nice to have the number of FileFlush since those are usually slow write operations blocking the caller (so an increase in theit number would be a regression to avoid).

For right now we are only running ts_paint with xperf. We are doing FileFlush vs DiskFlush as we found that with the Disk operations we would miss stuff in memory only. I looked at an older .etl file I had and I was unable to fine FileFlush operations in there, only DiskRead and DiskWrite operations. Could it be that during the simple startup test we don't do flush operations? I will also test this on non ts tests locally and see if I can see a FileFlush even in a log file. It could be as simple as a few lines of code in: http://hg.mozilla.org/build/talos/file/ca816866e975/talos/xtalos/etlparser.py

This bug has been around for almost 4 years, if we don't plan to work on it in the next couple of months, I would like to close it out. Please speak up if there are reasons to keep it open.

I think it's up to the Perf team to evaluate whether we still want such a test, so ni? Vladan. The idea by itself is still valid, having a test that runs common browser operations and counts FileFlush operations may be useful to notice regressions in blocking IO. Like during Tp. But I suspect Tp itself would show a regression, so it may not be critical to have a second metric. For Storage we have telemetry counting the number of fsyncs, and we have telemetry alerts so it is currently covered already. If it is trivial to count number of FileFlush during a Tp, it may be worth to report it as an additional data point, otherwise I think we'd better spend resources elsewhere.

Aaron: if adding FileFlush to the output is trivial, let's do it. Otherwise, let's wontfix for now

It's trivial to add FileFlush to the extracted data, but I suspect it is not so trivial to actually do anything with that such as raising an Orange.