Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit d3987a96 authored by Jintao Zhu's avatar Jintao Zhu
Browse files

logd: improve logd prune

upon memory usage high(>log_buffer_size), logd will try to prune(erase) all those old log elements which have been read by all readers for reclaiming the memory.  As such, a too slow reader will be a hinder to the success of the prune.  Logd has to try to kick-out the slow-est reader when memory usage is really too high(>2 * log_buffer_size).  But the kick-out operation is just a request to the reader and at what time the reader will exit is always uncertain, beyond control.  Furthermore, if you kick-out reader-A, waiting for A to exit; then, another reader-B may come in; then A exit; and then you kick-out-B, waiting for B to exit; and then, ...loop for ever: yes, logd may find that there seems to be always a slow reader hinder its pruning.  As we all know, that, logd will probably kick-out a slow reader(logcat), hence, indeed, almost all log capturing tools will try to re-connect logd immediately after it being kick-out-ed.  Such retry makes the issue easy to happen.  And, we observed that the reader thread may often be blocked by socket write operation, which hindering its exiting and hereby hindering the prune progress.  We need gracefully shutdown socket to relieve it from blocking and eventually stop such disaster from happening.

Test: monkey test for one day and one night

Change-Id: I5496ff74168b71e261914b91c145aa44814a5def
parent b81bc9ec
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment