Bring back starvation messages for single thread.
These kind of messages use to cause a lot of confusion, see b/37647467
binder thread pool (1 threads) starved for 4922 ms
However it is useful in some cases to find out some HAL is taking too
much time causing framework to freeze. (b/74187627)
And this log was good signal for bugs in the system in the past, usually
the scheduler but not always.
Bug: 74436227
Test: mma
Change-Id: I4706918d0938ec2eeba50429fa734a3b6253e35b
diff --git a/IPCThreadState.cpp b/IPCThreadState.cpp
index a93ecab..a1d448d 100644
--- a/IPCThreadState.cpp
+++ b/IPCThreadState.cpp
@@ -444,12 +444,15 @@
pthread_mutex_lock(&mProcess->mThreadCountLock);
mProcess->mExecutingThreadsCount--;
- if (mProcess->mExecutingThreadsCount < mProcess->mMaxThreads && mProcess->mMaxThreads > 1 &&
+ if (mProcess->mExecutingThreadsCount < mProcess->mMaxThreads &&
mProcess->mStarvationStartTimeMs != 0) {
int64_t starvationTimeMs = uptimeMillis() - mProcess->mStarvationStartTimeMs;
if (starvationTimeMs > 100) {
- ALOGW("All binder threads in pool (%zu threads) busy for %" PRId64 " ms",
- mProcess->mMaxThreads, starvationTimeMs);
+ // If there is only a single-threaded client, nobody would be blocked
+ // on this, and it's not really starvation. (see b/37647467)
+ ALOGW("All binder threads in pool (%zu threads) busy for %" PRId64 " ms%s",
+ mProcess->mMaxThreads, starvationTimeMs,
+ mProcess->mMaxThreads > 1 ? "" : " (may be a false alarm)");
}
mProcess->mStarvationStartTimeMs = 0;
}