MemoryInfra: write a wiki page for sheriffs on how strategies to debug memory alerts |
||||
Issue descriptionBackground context:go/memory-infra: memory profiling in chrome://tracing From internal thread: "Re: Current status of bisect on internal clank waterfall" (Keeping track of this on a more persistent medium. My inbox has proven to be more volatile than organic compounds.) Temporarily assigning to picksi@ to reduce the chances that we forget about this. picksi@ no direct action is expected on your side, other than reminding us about this :) from primiano@: ------- I think once this fire is over we should sit down and write down a "how to debug a memory alert" wiki page to explain all these strategies. Still feels bad to me that we have lot of data and we are not properly using it (and to be clear I think this on us, memory-infra. Usual lack of bandwidth / new problems jumping in our queues every week). I hope after the TBMv2 transition + new benchmarks we'll be able to sit down and figure out how to squeeze the most info out of this data. :) In the meantime a wiki page that explains how to do some basic analysis to humans might help the situation. ------- from sullivan@ ------- Thanks, Primiano! I think having a clear doc everyone can read on how we manually drill down will make it easier for speed infra team to support a better TBM2-based UI in the long term. -------
,
Oct 5 2016
,
Nov 25 2016
"Temporarily assigning to picksi@ to reduce the chances that we forget about this" I failed you all. I did completely forget about this :)
,
Nov 25 2016
I've just filed go/catabug/3035 which sounds exactly like this :) Maybe close that one and keep the discussion here?
,
Nov 25 2016
SGTM I have "won't fix"'d this bug :)
,
Jan 4 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by petrcermak@chromium.org
, Oct 5 2016