logd suffers major performance degradation when persistent (blocking)
client reader connects to it (e.g. logcat). The root cause of the
degradation is that each time when reader is notified of the arrival
of new log entries, the reader commences its search for the new entries
from the beginning of the linked list (oldest entries first).
This commit alters the search to start from the end of the linked list
and work backwards. This dramatically decreases logd CPU consumption
when blocking reader is connected, and increases the maximum logging
throughput (before the logs start getting lost) by a factor ~ 20.
Change-Id: Ib60955ce05544e52a8b24acc3dcf5863e1e39c5c
- create a structure to depict the private header
expected at logd end of socket.
- utilize this new structure instead of unscalable
byte stream technique used to unpack in logd.
Change-Id: I2d0e5c3531c279f2dc1fbd74807210ff8d804de0
In a scenario in which an on-line (blocking) client is running and
a clean is attempted (logcat -c), the following can be observed:
1) the on-line logger seems to freeze
2) any other clear attempt will have no effect
What is actually happening:
In this case prune function will "instruct" the oldest timeEntry
to skip a huge number (very close to ULONG_MAX) of messages, this
being the cause of 1.
Since the consumer thread will skip all the log entries, mStart
updating will also be skipped. So a new cleaning attempt will have
the same oldest entry, nothing will be done.
Fix description:
a. keep a separated skipAhead count for individual log buffers (log_id_t)
LogTimeEntry::LogTimeEntry
LogTimeEntry::FilterSecondPass
LogTimeEntry::skipAhead
LogTimeEntry::riggerSkip_Locked
b. update LogTimeEntry::mStart even if the current message is skipped
LogTimeEntry::FilterSecondPass
c. while pruning, only take into account the LogTimeEntrys that are monitoring
the log_id in question, and provide a public method of checking this.
LogTimeEntry::isWatching
LogTimeEntry::FilterFirstPass
LogTimeEntry::FilterSecondPass
d. Reset the skip cont befor the client thtread starts to sleep, at this point
we should be up to date.
LogTimeEntry::cleanSkip_Locked
LogTimeEntry::threadStart
Change-Id: I1b369dc5b02476e633e52578266a644e37e188a5
Signed-off-by: TraianX Schiau <traianx.schiau@intel.com>
- logDmesg method consumes considerable memory
resources (typically 128KB depending on kernel)
- In the future (eg: klogd, syslogd) there may be need to
feed multiple logs or threads with the retrieved data.
- By moving the actions of logDmesg into the mainline that
instantiates the thread objects, we can leverage a single
allocation of the the kernel log allocation.
- logDmesg (private) is replaced with log (public) which
has a more useful and descriptive purpose for the class.
Change-Id: Ie2dd0370661493c1e596a7e486904a0e8caab9ff
Impose a limit of 20 selinux denials per second. Denials beyond
that point don't add any value, and have the potential to cause
crashes or denial of service attacks.
Do some other misc cleanup while I'm here.
Bug: 18341932
Change-Id: I6125d629ae4d6ae131d2e53bfa41e1f50277d402
- Recognize pid=0 as special case (kernel or pre-init sourced)
and refrain from treating it in the general case.
Bug: 17526159
Change-Id: I74796043ac34753c6dd10018719ebc0bcd94e012
- simplify access and control exposure to class list
- indent
- compile warning
- Follow standard naming convention for variables and methods
- merge common fragments
- Side Effects: none
Change-Id: I74796043ac34753c6dd10018719ebc0bcd94e010
- sched_yield and lock synchronization in reader thread
startup to give writer thread a chance to catch up
Bug: 17512203
Change-Id: I43cf0b4e2829b22b3ab4e537fa95ce13c76a869c
Added parentheses as it was suggested by compiler.
error: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' [-Werror=parentheses]
Change-Id: Ic3746d9804488411d10d460ddfda11f1fad8efef
Signed-off-by: Arseniy Antonov <arseniy.antonov@intel.com>
- Correct default tense for kernel or user logger
- harden code that parses the benchmark data
- give more meaning to the spam filter test
Change-Id: I97699037ca9d56718f53f08d22be79092fb431de
- auditd spawn log copy to events and main
- logcat delete events as one of the default logs
- debuggerd do not collect events.
- squish multiple spaces
- switch from strcpy to memmove for overlapping buffers
BUG: 14626551
Change-Id: I89b30273ce931ed2b25a53ea9be48e77f4c1bbf4
- auditd switch to recording logs to events log id
- logcat add events as one of the default logs
- debuggerd collect events log as well.
ToDo: debuggerd & bugreport collect intermixed logs.
BUG: 14626551
Change-Id: I958f0e729b7596748be57488a38824db5645be7b
- AID_SYSTEM can set persist.logd.size
- AID_SYSTEM can issue command to /dev/socket/logd to
change the runtime global log sizes.
- Add support for ro.logd.size.* as populated by BoardConfig.mk
- Limit size to maximum ~3% of physical memory.
Bug: 14563261
Bug: 14627052
Change-Id: I606420db2e9d9d032296e71149e4a5b20cbd1137
- permits easier determination of logd thread at
fault in a stack trace from debuggerd.
Bug: 14275676
Change-Id: Iac2c523147e2bcce34ab7ddcecd02582c5fa7cc0
- Drop in-place sorting.
- Add fast-track for uid sizes and elements.
- Add sort() for per-uid and per-pid statistics.
Change-Id: Ib8655d4cc0b3bd4e87534522987bcc7fc7a5251a
- if network read/write broken up, reassemble the pieces.
- Use a 20ms poll to check if a new fragment has been
sent by the other side.
- fixup logd-unit-tests to take a (simplified) fragment
from the liblog changes.
Bug: 14164765
Change-Id: I98ff87888c119e1e8349717646d0f733e8971bc8
* Test statistics output, all four main log id types
are checked to be present, and output is properly
formatted with header (ascii new-line terminated
byte count) and trailer (newline formfeed) frames.
* On dev build test dgram_qlen, circumvent if
liblog benchmarks executed first though.
* Test if kernel and user space loggers are
present, and if any content has leaked to both.
* test benchmark and use it to verify worst UID pruning
Change-Id: I890c89f64825956f40108de806ed750b0170ac6c
