tree e5713f7c2d2e04766eabe36924f27804c3189102
parent 4b05d23b75aa6244890968c345d3a0ad16a4f130
author Tom Cherry <tomcherry@google.com> 1602890763 -0700
committer Elliott Hughes <enh@google.com> 1603127234 +0000

logd: don't use SCHED_BATCH

Receiving logs is interactive, particularly since processes may block
on having their logs be processed.  Receiving logs is not a batch
activity, since processing individual log messages is <10us on
average.  Further, the original commit that moved logd to SCHED_BATCH
doesn't show conclusive evidence that it helps solve any problems.

Recently, we've seen perfetto traces that show SCHED_BATCH actively
harming the system.  The below happens:
1) A process crashes and its recent logs are read to generate the
   tombstone
2) A log.reader.per thread is started, and since it has plenty of logs
   to send, remains scheduled for the full 1.5s timeslice that
   SCHED_BATCH allows.
3) The log.writer thread cannot run due to the above
   thread holding the logd lock.
4) Processes get blocked waiting for their messages to be processed by
   logd.

This change has logd use the default scheduler, which should give
log.writer cycles to handle incoming log messages, instead of allowing
log.reader.per to hog all of them.

Bug: 164973960
Test: pending
Change-Id: Icda6c9171ec98236fb91e0f29e6e09a6b443fc12