c581886eea
There are only three places where the log buffer lock is not already
held when the reader lock is taken:
1) In LogReader, when a new reader connects
2) In LogReader, when a misbehaving reader disconnects
3) LogReaderThread::ThreadFunction()
1) and 2) happen sufficiently rarely that there's no impact if they
additionally held a global lock.
3) is refactored in this CL. Previously, it would do the below in a loop
1) Lock the reader lock then wait on a condition variable
2) Unlock the reader lock
3) Lock the log buffer lock in LogBuffer::FlushTo()
4) In each iteration in the LogBuffer::FlushTo() loop
1) Lock then unlock the reader lock in FilterSecondPass()
2) Unlock the log buffer lock to send the message, then re-lock it
5) Unlock the log buffer lock when leaving LogBuffer::FlushTo()
If these locks are collapsed into a single lock, then this simplifies to:
1) Lock the single lock then wait on a condition variable
2) In each iteration in the LogBuffer::FlushTo() loop
1) Unlock the single lock to send the message, then re-lock it
Collapsing both these locks into a single lock simplifes the code and
removes the overhead of acquiring the second lock, in the majority of
use cases where the first lock is already held.
Secondly, this lock will be a plain std::mutex instead of a RwLock.
RwLock's are appropriate when there is a substantial imbalance between
readers and writers and high contention, neither are true for logd.
Bug: 169736426
Test: logging unit tests
Change-Id: Ia511506f2d0935a5321c1b2f65569066f91ecb06
|
||
|---|---|---|
| .. | ||
| doc_images | ||
| fuzz | ||
| .clang-format | ||
| Android.bp | ||
| AndroidTest.xml | ||
| ChattyLogBuffer.cpp | ||
| ChattyLogBuffer.h | ||
| ChattyLogBufferTest.cpp | ||
| CommandListener.cpp | ||
| CommandListener.h | ||
| CompressionEngine.cpp | ||
| CompressionEngine.h | ||
| LogAudit.cpp | ||
| LogAudit.h | ||
| LogBuffer.h | ||
| LogBufferElement.cpp | ||
| LogBufferElement.h | ||
| LogBufferTest.cpp | ||
| LogBufferTest.h | ||
| LogKlog.cpp | ||
| LogKlog.h | ||
| LogListener.cpp | ||
| LogListener.h | ||
| LogPermissions.cpp | ||
| LogPermissions.h | ||
| LogReader.cpp | ||
| LogReader.h | ||
| LogReaderList.cpp | ||
| LogReaderList.h | ||
| LogReaderThread.cpp | ||
| LogReaderThread.h | ||
| LogSize.cpp | ||
| LogSize.h | ||
| LogStatistics.cpp | ||
| LogStatistics.h | ||
| LogTags.cpp | ||
| LogTags.h | ||
| LogUtils.h | ||
| LogWriter.h | ||
| LogdLock.cpp | ||
| LogdLock.h | ||
| OWNERS | ||
| PruneList.cpp | ||
| PruneList.h | ||
| README.auditd | ||
| README.compression.md | ||
| README.property | ||
| README.replay.md | ||
| RecordedLogMessage.h | ||
| RecordingLogBuffer.cpp | ||
| RecordingLogBuffer.h | ||
| ReplayMessages.cpp | ||
| SerializedData.h | ||
| SerializedFlushToState.cpp | ||
| SerializedFlushToState.h | ||
| SerializedFlushToStateTest.cpp | ||
| SerializedLogBuffer.cpp | ||
| SerializedLogBuffer.h | ||
| SerializedLogChunk.cpp | ||
| SerializedLogChunk.h | ||
| SerializedLogChunkTest.cpp | ||
| SerializedLogEntry.h | ||
| SimpleLogBuffer.cpp | ||
| SimpleLogBuffer.h | ||
| auditctl.cpp | ||
| event.logtags | ||
| libaudit.cpp | ||
| libaudit.h | ||
| logd.rc | ||
| logd_test.cpp | ||
| logtagd.rc | ||
| main.cpp | ||
README.replay.md
logd can record and replay log messages for offline analysis.
Recording Messages
logd has a RecordingLogBuffer buffer that records messages to /data/misc/logd/recorded-messages.
It stores messages in memory until that file is accessible, in order to capture all messages since
the beginning of boot. It is only meant for logging developers to use and must be manually enabled
in by adding RecordingLogBuffer.cpp to Android.bp and setting
log_buffer = new SimpleLogBuffer(&reader_list, &log_tags, &log_statistics); in main.cpp.
Recording messages may delay the Log() function from completing and it is highly recommended to make
the logd socket in liblog blocking, by removing SOCK_NONBLOCK from the socket() call in
liblog/logd_writer.cpp.
Replaying Messages
Recorded messages can be replayed offline with the replay_messages tool. It runs on host and
device and supports the following options:
interesting- this prints 'interesting' statistics for each of the log buffer types (simple, chatty, serialized). The statistics are:- Log Entry Count
- Size (the uncompressed size of the log messages in bytes)
- Overhead (the total cost of the log messages in memory in bytes)
- Range (the range of time that the logs cover in seconds)
memory_usage BUFFER_TYPE- this prints the memory usage (sum of private dirty pages of thereplay_messagesprocess). Note that the input file is mmap()'ed as RO/Shared so it does not appear in these dirty pages, and a baseline is taken before allocating the log buffers, so only their contributions are measured. The tool outputs the memory usage every 100,000 messages.latency BUFFER_TYPE- this prints statistics of the latency of the Log() function for the given buffer type. It specifically prints the 1st, 2nd, and 3rd quartiles; the 95th, 99th, and 99.99th percentiles; and the maximum latency.print_logs BUFFER_TYPE [buffers] [print_point]- this prints the logs as processed by the given buffer_type from the buffers specified bybuffersstarting after the number of logs specified byprint_pointhave been logged. This acts as if a user calledlogcatimmediately after the specified logs have been logged, which is particularly useful since it will show the chatty pruning messages at that point. It additionally prints the statistics fromlogcat -Safter the logs.buffersis a comma separated list of the numeric buffer id values from<android/log.h>. For example,0,1,3represents the main, radio, and system buffers. It can can also beall.print_pointis an positive integer. If it is unspecified, logs are printed after the entire input file is consumed.nothing BUFFER_TYPE- this does nothing other than read the input file and call Log() for the given buffer type. This is used for profiling CPU usage of strictly the log buffer.