linux-kernel - Re: PROBLEM: high load average when idle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071002150748.906970bc.akpm@linux-foundation.org>
Date:	Tue, 2 Oct 2007 15:07:48 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Anders Boström <anders@...trom.dyndns.org>
Cc:	linux-kernel@...r.kernel.org, arjan@...ux.intel.com,
	torvalds@...ux-foundation.org
Subject: Re: PROBLEM: high load average when idle

On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
Anders Bostr__m <anders@...trom.dyndns.org> wrote:

> My computer suffers from high load average when the system is idle,
> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
> 
> Long story:
> 
> 2.6.20 and all later versions I've tested, including 2.6.21 and
> 2.6.22, make the load average high. Even when the computer is totally
> idle (I've tested in single user mode), the load average end up
> at ~0.30. The computer is still responsive, and the only fault seems
> to be the too high load average. All versions up to and including
> 2.6.19.7 is fine, and don't suffer from the problem.
> 
> I git bisect between 2.6.19 and 2.6.20 gave me
> 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 "[PATCH] user of the jiffies
> rounding code: JBD" as the first patch with the
> problem. 2.6.20 with 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 reverted
> works fine. 2.6.23-rc8 with 44d306e1508fef6fa7a6eb15a1aba86ef68389a6
> reverted also works fine.
> 
> This fixes the problem:
> 
> -------------------------- fs/jbd/transaction.c -----------------------------
> index cceaf57..d38e0d5 100644
> @@ -55,7 +55,7 @@ get_transaction(journal_t *journal, transaction_t *transaction)
>  	spin_lock_init(&transaction->t_handle_lock);
>  
>  	/* Set up the commit timer for the new transaction. */
> -	journal->j_commit_timer.expires = round_jiffies(transaction->t_expires);
> +	journal->j_commit_timer.expires = transaction->t_expires;
>  	add_timer(&journal->j_commit_timer);
>  
>  	J_ASSERT(journal->j_running_transaction == NULL);
> 
> 
> I've only seen this problem on my home desktop computer. My work
> desktop computer and several other computers at work don't suffer from
> this problem. However, all other computers I've tested on is using
> AMD64 as architecture, and not i386 as my home desktop computer.
> 
> Please let me know how I can assist in further debugging of this, if
> needed.

This is unexpected.  High load average is due to either a task chewing a
lot of CPU time or a task stuck in uninterruptible sleep.

Can you please work out which of these is happening?  Run `top' on an idle
system.  Is the CPU less than 1% loaded?

Run

	ps aux | grep " D"

or something like that on an idle system, see if you can spot a task which
is spending time in D state.

If there's a task whcih is spending time in D state, try running

 echo w > /proc/sysrq-trigger ; dmesg -c > foo

the check "foo" to see if it has a task in D state (search foo for " D "). 
If it's not there, do the sysrq again, repeat until you've managed to
capture a trace of the blocked task.

If it turns out that the CPU really is spending excess amounts of time
being busy then a kernel profile would be a good way of finding out where
it is spinning.  Or run sysrq-P from the keyboard a few times.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/