tree 7c45dcdd9ee69841f415e0f4bc38e327320f8b0f
parent 31bc6982a4b4ab0c636054f26b7fce0b473c5125
author Christopher Tate <ctate@google.com> 1268960103 -0700
committer Christopher Tate <ctate@google.com> 1268961237 -0700

Ensure that binder incalls to the system process keep the fg cgroup

On binder incalls, the handler thread is given the caller's priority by the
driver, but not the caller's cgroup.  We have explicit code that sets the
handler's cgroup to match the caller's, *except* that the system process
explicitly disables this behavior.  This led to a siuation in which we were
running binder incalls to the system process at nice=10 but cgroup=fg.

That's fine as far as it goes, except that if a GC happened in the handler
thread, it would be promoted to foreground priority and cgroup both, to avoid
having the GC take forever.  Then, when GC finished, the original priority
is reset, and the cgroup set *based on that priority*.  This would push the
handler thread into nice=10 cgroup=bg_non_interactive -- which matches the
caller, but is supposed to be impossible in the system process.

The end result of this was that we could be running "lengthy" operations in
the system process in the background.  Unfortunately, some of the operations
that wound up like this would hold important global system locks for up to
twenty seconds as a result, making the entire device unresponsive to input
for that period.

This CL fixes the binder incall setup to ensure that within the system process,
a binder incall is always begun from the normal foreground priority as well
as cgroup.  In practice now the device still becomes laggy/sluggish when the
offending lock-holding time-consuming incall occurs, but since it still runs
as a foreground task it is able to proceed to completion within a short time
rather than taking 20 seconds.

Fixes bug #2403717

Change-Id: Id046aeabd0e80c48eef94accc37842835eab308d