I agree - the goal of the code was never to wait on locks for any amount of time. I'm actually a little surprised that the locks in use can block for this duration. There are two locks:

context_lock_ - we never wait on this, we try to acquire it, and if we fail, we return. This is the lock I expect to see contention on.

current_idle_generation_lock_ - we hold this while modifying current_idle_generation_ - should not ever block for long. There is a currently a bug where we actually hold this while calling TaskRunner::PostDelayedTask - so maybe if that can block for a long time we could hit this. However, I wouldn't expect TaskRunner::PostDelayedTask to block for long?

I'll put together a CL to address this issue - hopefully that will fix things.

It does seem odd that PostDelayedTask would block for a long time. If it is blocking then that will probably cause other problems which means that the proposed fix - while generally a good idea (don't hold locks for longer than necessary) is addressing more symptoms than cause.

An ETW trace (go/etw) would probably let us figure out what was going on because it captures all threads blocked on locks, who readied whom, CPU and disk usage, etc. But, it's not normally running. If this happens again then maybe leave UIforETW running in the background with tracing running, set to circular buffers. This has very low overhead and is perfect for this kind of rare performance problems. If the bug happens again then type Ctrl+Win+C (or press Save Trace Buffers) after the system has recovered to save the circular buffers to disk. They will record the last twenty to sixty (roughly) seconds of system activity. I can analyze the trace.

note: chrome://profiler is counter-intuitive, "Function name" is the function that *posted* the task (the FROM_HERE), not what's executing.
What took long is not PostDelayedTask, but ContextCacheController::OnIdle

This is likely a dup of several other instances such as crbug.com/661306, crbug.com/703342,  crbug.com/667820  or  crbug.com/697703  where everything points to the IO thread being blocked, and preventing communication with the GPU process.

piman@, I vaguely recall you making some changes to prevent blocking in OnIdle (or maybe in flush, which is used by that). I found this CL, but couldn't remember if there were others: https://chromium-review.googlesource.com/c/chromium/src/+/634469

If this is likely addressed, let's close this out.

SetAggressivelyFreeResources should not block any more. I'm not sure if GrContext::purgeUnlockedResources might block, but I would assume not.

I don't see evidence of crashes or hangs inside of OnIdle (which used to happen in the past), so I will mark this as fixed (feel free to reopen with new evidence if it is not).