commit ed9e779baf55f30dddc13ebeeceb37f33b9fb878
author Douglas Anderson <dianders@chromium.org> Tue Apr 12 03:03:58 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Apr 12 03:03:58 2022
tree 39efe9ff0bf3148c4eaa82c1d21bd5de4ad26d77
parent c17345198618a8e15f3230175c3b5130ee4b2100

gpu: Turn use_virtualized_gl_contexts on for freedreno on Chrome OS

On freedreno, each GL Context allocates a thread in the GPU
process. The default stack size for a thread is 8MB. We currently run
Chrome in 32-bit mode on arm64 processors. If we could use the entire
32-bits of address space for stacks (we can't) then we'd be limited to
512 threads. In reality, we see that we start failing to create new
threads at ~230. In tast.platform.MemoryPlatform this seems to happen
after creating about 30 tabs. Then the GPU process crashes. It turns
out that when the GPU process crashes we actually recover pretty well,
but this is still not ideal.

Note that in the above, we don't _actually_ run out of memory. We
instead run out of virtual address space. Though stacks are allocated
at 8MB per thread I believe they are allocated lazily so we're not
truly using 4GB of RAM just for stacks. This means that the problem
will go away when we transition to 64-bit userspace.

It should also be noted that we can tweak mesa to create smaller
stacks, though depending on how much we shrink it there could be risk
here. In my case, I had no problem running the full
tast.platform.MemoryPlatform test even with 32k stacks, but I also
wasn't running anything that particularly stressed the GPU.

Despite the fact that the crash will go away with 64-bit and the fact
that we could shrink the stack size, it's been proposed that the
_correct_ fix is to just enable virtualized GL contexts. Why?
* GL Contexts on mesa are fairly heavy even if we get rid of the stack
  allocation. Some quick estimates put them between 1MB and 3.5MB.
* Chrome is not shy about allocating contexts. With only 30 tabs
  opened we had 230 contexts open. Ideally we should be able to open
  ~90 tabs on a 4GB machine. That could give us 600 MB - 2.4 GB more
  memory.
* It turns out that almost all ARM vendors are using virtualized GL
  contexts today for one reason or the other, so this is a well-tested
  and well supported path.

Let's turn virtualized GL contexts on for freedreno.

In testing, this didn't seem to make a huge difference in the number
of tabs that platform.MemoryPressure reported it could open. I ran
twice without this change and twice with it. Differences are within
the noise, I believe. On one machine:
  Without this change: 83 tabs, 78 tabs
  With this change:    81 tabs, 77 tabs
...of course, without this change the GPU process crashed and
restarted twice per test run.

I guess the likely explanations for why we didn't get dramatically
more tabs:
* Maybe GL contexts don't really take up 1MB - 3.5MB
* Maybe the overhead of each "virtual" GL context is similar to a
  real Gl context.
* Maybe the GL contexts compress well and thus don't take up much
  space when combined with zram.

Whatever the reason, turning on virtualized GL contexts doesn't seem
to be a huge negative or anything and, at least for now, they help
keep our GPU process from crashing.

NOTE: it's been suggested that perhaps we should kick off an
experiment to turn virtualized GL contexts across the board for all
platforms including x86. That seems like a good next step but will
take a while. Let's fix it so that the GPU process doesn't crash at
~30 tabs right away but just leveraging the existing "workarounds"
list. If it turns out that virtualized GL contexts _aren't_ a savings
across the board we can always turn off this workaround when we get to
64-bit userspace.

BUG=b:227246804
TEST=chrome://gpu shows workaround
TEST=tast run ${DUT} platform.MemoryPressure # ps -T -p ${GPU_PID}

Change-Id: I5f2364f31e6531a994b0c94665e00f53369d98aa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3577408
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Cr-Commit-Position: refs/heads/main@{#991344}