Is moka constantly using CPU normal?

[mu-arch]

I notice Moka seems to be constantly using CPU (an extremely small amount, but it is curious)

Here's a flamegraph showing moka using 89% of the CPU time my application is running. In this time span less than 100 reads and writes combined were made. I'm curious if as my application scales up this high CPU use will stay the same or get worse?

My OS reported that in this time my binary used 17:50 of CPU time, meaning 15.575 of that time was just spent on Moka doing whatever it does, not exactly great.

[tatsuya6502]

Hi. Sorry for not getting back to you sooner. I did not notice your question until now.

Currently, some parts of Moka is not fully optimized, and its housekeeper will wake up and run every 300 milliseconds even when there might be nothing to do. Under the current implementation, the housekeeper will acquire an internal lock, check if there is any task (and run the task), and then unlock and schedule its next run using scheduled_theadpool crate.

However, I am expecting it will have very small overhead when there is no task available.

I am not sure how to interpret this flamegraph. I see scheduled_theadpool spent almost all time for parking a thread (parking_lot::park), which means threads were waiting for next task to become available and should not consume much CPU time. So I guess the flamegraph is not showing that Moka is using 89% of the CPU time, but showing that Moka is putting its thread pool sleeping most of the time?

(parking_lot::park may do some spin lock in very short time before putting the thread in blocked state, but I doubt it will take up that much of the CPU time)

[mu-arch]

I am fairly noobie at interpreting flamegraphs when it comes to things like locks. However, I did compare my application with and without Moka and noticed the higher CPU consumption with Moka to validate what I was seeing here. I'll revisit this thread later as I collect more information when I test my application under heavy load.

[tatsuya6502]

I'll revisit this thread later as I collect more information when I test my application under heavy load.

Thanks. That would be helpful.

If possible, please share the followings:

1. The original SVG file of the flamegraph, so that I can dig into more details.
2. What OS are you using? (e.g. Linux x86_64)
3. How did you correct the trace data? (e.g. eBPF)
4. How long did you run the trace? (e.g. 5 minutes)
5. What was the average CPU utilization (% busy) while tracing.
6. Did you use a release build (e.g. cargo run --release) or a debug build (e.g. cargo run)?

I did a bit research on flamegraph with thread sleeping. And maybe you are right; these parking_lot park()s might be taking CPU time rather than sleeping. CPU flamegraph seems to show only the code-paths that are hot (busy on-CPU).

• https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

parking_lot lock_slow() does some spin lock before park()ing to acquire a lock. And it causes a CPU core 100% busy in a very short period (less than a few micro seconds, I guess). Maybe this is increasing the CPU consumption?

https://crates.io/crates/parking_lot

• (4) Microcontention (a contended lock with a short critical section) is efficiently handled by spinning a few times while trying to acquire a lock.
• (5) The locks are adaptive and will suspend a thread after a few failed spin attempts. This makes the locks suitable for both long and short critical sections.

https://github.com/Amanieu/parking_lot/blob/28bf1aae07e453fa9acd675a4a6e469b28df7ff8/core/src/spinwait.rs#L11-L18

// Wastes some CPU time for the given number of iterations,
// using a hint to indicate to the CPU that we are spinning.
#[inline]
fn cpu_relax(iterations: u32) {
    for _ in 0..iterations {
        spin_loop_hint()
    }
}

hint::spin_loop: https://doc.rust-lang.org/stable/std/hint/fn.spin_loop.html

Emits a machine instruction to signal the processor that it is running in a busy-wait spin-loop (“spin lock”).

Upon receiving the spin-loop signal the processor can optimize its behavior by, for example, saving power or switching hyper-threads.

...

A common use case for spin_loop is implementing bounded optimistic spinning in a CAS loop in synchronization primitives. ...