search for: cpu_load

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

...942] .nr_load_updates : 22334 [ 386.319945] .nr_uninterruptible : 3 [ 386.319948] .next_balance : 4294.988996 [ 386.319951] .curr->pid : 3590 [ 386.319954] .clock : 386317.815742 [ 386.319957] .cpu_load[0] : 0 [ 386.319960] .cpu_load[1] : 0 [ 386.319962] .cpu_load[2] : 0 [ 386.319965] .cpu_load[3] : 0 [ 386.319967] .cpu_load[4] : 0 [ 386.319970] .yld_count : 0 [ 386.319973]...

...157] .nr_load_updates : 19627 [ 413.409157] .nr_uninterruptible : -100 [ 413.409157] .next_balance : 4295.080712 [ 413.409157] .curr->pid : 0 [ 413.409157] .clock : 413408.021911 [ 413.409157] .cpu_load[0] : 0 [ 413.409157] .cpu_load[1] : 0 [ 413.409157] .cpu_load[2] : 0 [ 413.409157] .cpu_load[3] : 0 [ 413.409157] .cpu_load[4] : 0 [ 413.409157] cfs_rq[0]:/ [ 413.409157] .exec_clock...

I''ve been working on running down intermittent ENOSPC issues. I can only seem to replicate ENOSPC errors when running zlib compression. However, I have been seeing similar ENOSPC errors to a lesser extent when playing with the LZ4HC patches. I apologize for not following up on this sooner, but I had drifted away from using zlib, and didn''t notice there was still an issue. My

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

...e [cbd] is a module developed by us, I think this bug has nothing to do with it. And the contents of rq in pick_next_task(struct rq *rq) is (see attachement for full contents of struct rq): struct rq { lock = { raw_lock = { slock = 67109881 } }, nr_running = 2, cpu_load = {0, 5923, 14993, 13888, 9115}, last_load_update_tick = 4365159236, nohz_balance_kick = 0 '\000', skip_clock_update = 0, load = { weight = 2, inv_weight = 0 }, nr_load_updates = 21530842, nr_switches = 148355748, cfs = { load = { we...