Design and Optimization of Low Power Persistent Logging System Based on Embedded Linux

The log collection module employs the kernel logd channel as the primary entry point, with reception frequency controlled at 50–150 entries/s and the resident collection thread limited to 128KB memory. To enhance concurrent throughput, the architecture adopts a multi-threaded producer–consumer model: the collection thread captures and pre-processes logs, parsing threads format and structure them, and writing threads commit data into the cache. Threads are decoupled via a ring queue optimized for lock granularity, which improves scheduling efficiency under high-frequency loads. To minimize main-core wake-ups, a hierarchical priority queue unifies Kernel, Event, and Main logs into a single asynchronous flow, mitigating delay fluctuations from lock contention[2]. Each log undergoes pre-processing in <2ms, with 4KB-aligned blocks providing structured cache encapsulation. An LRU elimination strategy with adaptive heat-threshold adjustment accelerates hotspot log handling. The system caps collection capacity at 20,480 bytes/s, redirecting overflow into a delay buffer to prevent frequent write triggers. Under low load, thread wake-up intervals stretch dynamically beyond 100ms. data is compressed through a marking table, reducing per-record overhead from 64B to <28B, thereby lowering disk I/O burden.

The log persistence process is designed with a double-buffer structure, with each write buffer size fixed at 64KB, aligned with the flash page. The main write thread passively triggers the disk drop operation when the buffer threshold exceeds 60% or the residence time exceeds 800ms. This thread acts as the core thread on the consumer side, and writes to the ext4 log partition in a sequential append mode to reduce write amplification and data updates. The system integrates a file rotation mechanism that writes compressed logs to partitions in fixed segments (e.g., 512KB), and automatically names and archives old files when the threshold is exceeded. The rotation policy supports switching between three modes based on time windows, capacity thresholds, or event triggers to ensure that the logs grow in a controlled manner and are easy to analyze. Meanwhile, to further reduce the frequency of wake-up and writing events, the system enhances the write throttling algorithm by incorporating a closed-loop feedback control model inspired by PID regulation principles. Rather than solely reacting to instantaneous queue backlog or I/O load, the new scheme estimates the writing pressure trend using a feedback vector composed of historical latency fluctuation, power consumption gradient, and log burst frequency. The throttling threshold and sleep cycle are dynamically tuned by calculating the error margin between expected and actual write rate, and the derivative of backlog variance, ensuring adaptive suppression of transient I/O spikes. This proactive control model improves write scheduling responsiveness under variable workloads while maintaining log persistence stability.The write cycle is strictly limited to the I/O idle window, and the average wake-up frequency does not exceed 6 times per minute. Before each log is persisted, 8-byte CRC verification is performed to provide structural boundary identification support for subsequent rotation and recovery.

The log compression module employs a lightweight multi-strategy framework, with LZ4 block compression as the main path and RLE as in-line compensation. Each 4KB fragment carries a control byte for format identification. We compared LZ4 with Zstandard and Snappy, both optimized for log patterns. Results show LZ4 achieves a 2.46:1 ratio with 0.89 ms latency per block, Zstandard 2.83:1 but 1.94 ms latency, and Snappy 2.31:1 with 1.15 ms. Considering embedded power and real-time constraints, LZ4 offers the best balance, particularly for repetitive key-value pairs and structured JSON logs prevalent in smart glasses systems, thus remaining the preferred scheme[3]. To support fast localization, compressed segments use intra-segment relative indexing and 8-byte alignment. The decoder maintains 16 hot-path caches with >80% hit rate, reducing decode cost. Figure 1 visualizes the same segmentation window before and after compression, showing key-field reduction and fill-zone alignment. This module also shares the log index header with the file rotation strategy, forming a unified access portal.

The power consumption control design of the low-power persistent logging system builds a three-phase scheduling model based on the state migration diagram, and this design idea can also be seen in the energy consumption governance mechanism of distributed sensing terminals such as smart glasses[4]. As a core wake-up source, the log writing behavior is scheduled by the event poller on a cycle-constrained basis, with the default cycle set to Δt, and each write triggers a soft interrupt wake-up. To precisely control the energy consumption surge, the system defines the total power consumption expression as: where P_idle is the standby power consumption, P_wake is the instantaneous power consumption of each wakeup, T_w indicates the wakeup time, P_write is the write power consumption, T_wr indicates the write time consumption, and n,m is the number of triggers per unit time. Further, the system compresses the total number of wakeups with a delayed trigger mechanism: where T_window is the total observation window, T_interval is the minimum period, and δ is the dynamic delay offset. In order to control the impact of writing to the dense area, the log buffer also introduces an energy consumption threshold detection module, which needs to fulfill the conditions before writing: where E_remain is the cycle remaining energy budget. Figure 2 gives the level response diagram of typical state switching in the design of low-power persistent logging system for embedded Linux, demonstrating the change patterns of level pulses in the system in the three states of idle, write, and wake-up, with the low level maintaining the master dormant and the high level pulses corresponding to the compressed write behavior triggering cycle, and the bandwidth window structure embedded with a dynamic wake-up indexing table, working in concert with the upper-layer QoS policy.

The memory cache design adopts a four-level hierarchical stacking model aimed at optimizing write latency and reducing I/O bursts. The inner-most layer is a 64KB write buffer; the mid-layer is a time-ordered index queue (size: 512); the outer layer is a 256KB LZ4-compressed intermediate buffer; and the outermost staging area supports deferred flush alignment. To validate the design’s effectiveness, we model the cache stack using a tandem queuing system under M/M/1 assumptions. Log write requests are approximated as a Poisson process (arrival rate λ ≈ 22 req/s), and service rate μ is defined by encoding and flash commit latency. Letting each level i have a service time μᵢ, the total delay is represented as D = Σ(1/(μᵢ − λ)), under stability constraint μᵢ > λ. Simulation shows that the overall cache hit ratio remains above 94% when λ ≤ 24/s, and write latency remains within 2.5ms on average. This confirms that the multi-stage buffering queue system maintains low overflow probability and high throughput, supporting the cache design’s near-optimality for constrained embedded environments. Due to the frequent scheduling of the main thread caused by the pre-write logic delay fluctuations, the optimization scheme introduces a response time prediction model, whose function is defined as follows: where S_i is the original size of the first i log, C_buf is the cache capacity, H(i) indicates the historical hit rate of the address, E_cell(i) is the current Flash cell wear level, and α,β,γ is the tuning weight parameter. The erase balancing strategy relies on the erase heat mapping table, which is similar to some of the design strategies for Flash lifetime optimization in assisted smart wearable devices[5], and improves the storage reliability; the page-block mapping table contains a total of 1024 blocks of 8K pages, and each block records the erase counts once, and schedules the static balancing mechanism once every 10 seconds on average. Figure 3 shows the design of low-power persistent logging system for embedded Linux Flash area erasure heat map, the darker the color block indicates that the higher the frequency of erasure, the figure can be seen in the balancing mechanism has been effectively dispersed distribution of hot blocks, effectively alleviating the problem of single-area aging.

The experimental platform is selected from the customized smart glasses prototype device[6], and the relevant test parameters are listed in Table 1.

Power consumption is measured through a synchronized three-channel sampling scheme, revealing that the main control chip exhibits pronounced peaks during burst writes—an issue critical when users interact with smart glasses while walking[7]. To capture finer energy behavior, we profiled power at the component level across three states: static standby, high-frequency burst write, and low-frequency steady write. Synchronized probes monitor CPU core, memory controller, Flash interface, and SoC bus rails. Table 2 details per-component energy cost as both absolute power and relative share of total dynamic consumption. The write phase is further decomposed into log parsing, compression, and Flash commit, exposing transient peaks. This granularity highlights dominant energy consumers under varying workloads and provides guidance for hardware-assisted logging acceleration.

Table 2 provides a detailed breakdown of power consumption across core system components under different operational states. In the static standby phase, CPU power dominates at 5.4 mW, accounting for over 55% of total system energy, indicating that even in idle states, background thread residency contributes significantly. During high-frequency burst writes, Flash interface consumption spikes to 14.2 mW (24.6%), revealing its sensitivity to intense write bursts. The CPU maintains a high load (46.4%), mainly due to compression and indexing activities. The memory subsystem remains relatively stable across phases, with slightly elevated draw in the cache refresh window (8.2 mW), suggesting that background LRU management and buffer scanning contribute to power drift. Notably, the bus interface, although low in absolute power, consistently consumes around 8–9% of total energy, underscoring its persistent communication overhead. These results reveal the dual bottlenecks of CPU and Flash in energy hotspots, and point toward further gains through workload offloading or hardware compression modules.

The log storage performance test evaluates partition I/O throughput and log write latency across three processes: concurrent multi-threaded writing, file rotation, and compression with disk drop. Control variables include cache size (128KB/256KB/1MB) and compression mode (LZ4 Fast vs. LZ4 HC). Sampling is performed at 10Hz with 36,000 samples in total. The system runs on a smart-glasses prototype, whose I/O sensitivity optimization references stability techniques from wearable identity systems based on acoustic sensing[8]. Table 3 lists the storage performance test results with different caching and compression strategies.

The overall write latency tends to decrease after the cache capacity is increased, with the lowest average write latency of 2.12ms for 1MB configuration. In contrast, LZ4 HC improves the compression ratio but brings encoding overhead in the rotation trigger phase, resulting in an increase in the single rotation time to 112ms.The throughput rate grows steadily with the cache size, with a maximum improvement of 26.7%. The low-power persistent logging system design for embedded Linux maintains good partition I/O performance in highly concurrent write scenarios, providing a performance boundary reference for platform-level deployments.

The validation test covers three types of failure scenarios: power failure reboot, kernel abnormality triggering and process interruption recovery, and the test objective is to assess the consistency of the log structure and data reorganization capability. The experiment uses cyclic writing of 100,000 logs, each of which is appended with 8-byte CRC code, and after system reboot, integrity checking and record recovery operations are performed, To further verify the durability of the system in extreme fault scenarios, this paper extends multiple high-voltage recovery scenarios based on the original testing. In addition to standard sudden power outages, kernel crashes, and write interrupts, new situations such as "continuous power outages (batch 20 times)", "cache refresh interrupts", and "forced interrupts when Flash space approaches its limit" have been added. Each round of testing uses 100000 log writes (with 8-byte CRC check), automatically restarts after triggering a fault, and performs integrity check and log recovery. Table 4 summarizes the various test indicators. The low-power persistent logging system for embedded Linux is designed to load the header of the cache structure according to the rotation order of the logs in each round of recovery and rebuild the write pointer offset index, so as to avoid repetitive writes and cross-page frame breaking problems. The single recovery time is limited by the unfolding rate of the compressed segment index structure, which is kept within 0.38 seconds on average.

Table 4 presents a comprehensive evaluation of the logging system's resilience under multiple abnormal scenarios. In standard sudden power-off and kernel crash tests, the system consistently maintained full segment recovery and zero or near-zero data loss, validating the robustness of the dual-buffer and index-tracking mechanisms[9], Under batch power-off stress (20x), no logs were lost, and CRC failures remained low (4), demonstrating stability under repetitive voltage disruptions. In more aggressive cases—such as mid-flush power loss and flash quota exhaustion—the system experienced up to 5 CRC failures and a slight decline in segment reorganization success (down to 96.2%). However, even in these worst-case conditions, misplaced indexes remained minimal[10]. These results indicate that the system can tolerate high-frequency interruptions and partial write inconsistencies while ensuring strong structural recovery and log retention.